- 博客(381)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 用Terraform模块化改造：我把基础设施代码从800行压到120行
Terraform 模块化不是简单的"把大文件拆成小文件"。真正的价值在于建立清晰的分层契约：资源模块负责技术细节，环境模块负责业务组装，根模块负责最终实例化。三层各司其职，修改任何一层都不会破坏其他层的稳定性。重构后的 120 行代码不是炫技，而是把复杂度关进了模块的黑盒。业务方看到的永远是简洁的接口，实现细节对他们是透明的。这才是基础设施即代码应该有的样子。如果你也正在维护一个臃肿的 Terraform 项目，不妨从提取第一个资源模块开始——通常 VPC 或 ECS 是最佳切入点。
2026-04-20 09:13:32
34
原创 用 eBPF 揪出生产环境隐藏的 N+1 查询：一次从 300ms 到 30ms 的 PostgreSQL 性能抢救
第一，慢查询日志不是万能的。单条 SQL 执行快，不代表请求整体快。N+1 的每条查询可能就 5ms，但 20 条加起来就是 100ms，再加上网络 RTT，很容易就突破 300ms。第二，eBPF 确实香。不需要改代码、不需要重启服务，直接在内核层看见应用和数据库之间的真实交互。以后这种「查不到慢查询但接口慢」的诡异问题，我第一反应就是上 eBPF。# pg_n1_detector.bt - 检测 N+1 模式的 bpftrace 脚本BEGIN {
2026-04-19 15:05:41
172
原创 K8s Pod 反复 CrashLoopBackOff，我用 kubectl debug 和 events 日志 10 分钟锁定僵尸进程
先看 events 找线索，再用 debug 容器进现场验证。很多人遇到 CrashLoopBackOff 就只会，但日志里没报错的时候往往会卡住。# 1. 看事件，找杀容器的真凶# 2. 进现场，像调试本地进程一样调试容器# 3. 查资源限制，确认是否触及系统边界僵尸进程这个问题，在容器环境里其实挺常见的——很多人以为容器是「用完即走」，就忽略了进程回收。但 Linux 的 PID 是全局资源，容器里也一样。父进程不 wait()，子进程变僵尸，累积多了系统就垮了。
2026-04-19 09:10:05
291
原创 凌晨3点被告警炸醒：Flink 作业背压导致全链路延迟飙升，我用反压指标定位了源头
折腾到凌晨 5 点，延迟终于压回了 3 秒以内。虽然熬了个通宵，但也补上了一直忽视的背压监控这块短板。代码里有没有同步调用外部服务？Web UI 的 Backpressure Tab 有没有在看？作业有没有配置背压相关的告警？别让监控全绿的假象骗了。背压这种"软故障"，才是最恶心的。Flink Backpressure 官方文档。
2026-04-18 15:08:45
336
原创 MongoDB 副本集脑裂导致脏写，我用 priority + votes 重选举机制 15 分钟止血
说实话，MongoDB 副本集的脑裂问题说实话不是新鲜事，但每次遇到都让人头疼。高可用不是配置一次就完事了，需要定期检查、定期演练。定期检查，确认各节点状态正常滚动升级前先跑一遍提前把priority和votes配好，别等出事了再临时抱佛脚好了，就说这么多。如果有问题，欢迎评论区交流。
2026-04-18 09:11:47
201
原创 Redis 缓存雪崩导致核心接口 RT 飙升 10 倍：我用热点 Key 探测 + 本地缓存兜底救活了库存服务
指标优化前优化后提升P99 响应时间180ms12ms93%↓Redis QPS50,00020,00060%↓MySQL 连接数峰值80015081%↓本地缓存命中率0%75%说实话，这套方案不是银弹。本地缓存会带来数据一致性问题，所以只适合读多写少的场景。另外，本地缓存的容量有限，不能把所有热点 Key 都塞进去，需要做好容量规划。缓存雪崩这个问题，防比治重要。热点 Key 过期时间加随机偏移：避免大量 Key 同时失效本地缓存兜底。
2026-04-17 15:08:08
196
原创 一次 gRPC 连接池配置失误，让 P95 抖成心电图：我是怎么用 Channelz 和 eBPF 抓到真凶的
gRPC 的问题，很多时候不在业务代码，而在连接策略。参数单看都合理，放在真实链路里可能互相“打架”。如果你愿意，我下一篇可以把“Java/Go 两套 gRPC 连接治理基线配置”整理成可直接拷贝的模板，附压测脚本和告警规则。
2026-04-17 09:09:49
216
原创 一次JWT密钥轮换引发的线上雪崩：我总结的三步无损热切换方案
JWT密钥轮换是个典型的"平时不觉得，踩坑才知道"的事儿。我们那次事故持续了大概40分钟，影响了将近1小时内的全部登录请求，事后复盘发现完全可以避免。永远不要瞬间轮换，新密钥上线后至少保留旧密钥1-2周签发和验证要分开，签发用新密钥，验证接受新旧并行监控token来源分布，根据实际数据决定何时下线旧密钥如果你正在准备做JWT密钥轮换，希望这篇文章能帮你少踩一个坑。如果你们团队有更好的方案，欢迎留言交流。
2026-04-14 09:29:55
319
原创 Kubernetes Pod 反复 OOMKilled，我最后不是调内存，而是先修了这份启动脚本
容器里的 Java 应用，不能光调 JVM 参数，还得管启动脚本。特别是这种「启动阶段 OOMKilled、跑起来就没事」的情况，大概率是启动脚本没有正确感知容器 limit，导致 JVM 以为自己有 unlimited memory，疯狂分配。下次再遇到 Pod OOMKilled，别急着加内存，先看看启动脚本里有没有正确设置。有问题欢迎评论区交流，也欢迎分享你踩过的类似坑。
2026-04-13 09:16:19
207
原创 Prometheus 告警规则一团糟？我用一个脚本把 200 条规则按严重性自动分级
好的监控系统不是规则越多越好，而是每一条告警都能准确、及时地传达有用信息。那个 200 多条规则的仓库，现在缩减到了 89 条。虽然数量少了，但每一条都知道它在监控什么、什么情况下触发、触发后该怎么做。如果你也面临类似的告警混乱问题，不妨试试这个思路：先分级、再清理、最后规范。工具只是手段，目的是让告警重新变得可信。完整的脚本我放在（可自行搜索 prometheus-rule-linter），有类似困扰的同学可以参考。文中脚本已脱敏处理，实际使用时请根据你的规则结构调整正则表达式。
2026-04-12 10:25:15
295
原创 把发布回滚时间从 20 分钟压到 3 分钟：我在 CI/CD 里补上的 4 个保险丝
这 4 个保险丝加起来，把发布风险从"手动救火"变成了"自动容错"。从 20 分钟到 3 分钟，不只是时间缩短，更是把"人的不确定性"从流程中去掉了。先加日志：每次发布都记录，方便定位问题再加监控：健康检查要真的"健康"，不只是返回 200然后自动化：能用脚本的别用手，能自动回滚的别等人最后准备预案：一键回滚脚本要随时可用，最好能从手机触发说到底，运维的核心不是避免出问题，而是出了问题能多快恢复。与其指望凌晨 2 点脑子清醒，不如让系统自己解决。
2026-04-10 15:37:16
370
原创 Elasticsearch 索引写入突然卡死？我用 _cat API 和线程池监控定位了元凶
ES 的线程池监控太重要了。很多 ES 问题表面上是索引慢、查询慢，但根因往往是线程池被打满。而 _cat API 是定位这类问题的利器，比翻日志快得多。批量写入一定要限流：别让定时任务无脑并发，ES 扛不住refresh_interval 别设太小：除非实时性要求极高，否则 30s 够用分片规划要提前做：根据写入量估算分片数，别等打满再改线程池队列要监控：队列堆积是写入瓶颈的早期信号如果你也遇到 ES 写入卡死的问题，先别急着查 mapping，看看线程池队列再说。相关命令速查。
2026-04-10 09:41:27
379
原创 一次慢 SQL 不是数据库的锅：我怎么用 EXPLAIN 和采样日志定位真正瓶颈
慢SQL不一定都是数据库的锅。这次故障排查花了2小时，但真正解决问题只用了10分钟。大部分时间都在"以为是数据库问题"的错误方向上。关键教训：遇到慢SQL，先别急着改索引，用EXPLAIN和采样日志确认瓶颈在哪一层。工具分享：我写了一个自动化采样脚本，放在GitHub了，大家可以拿去用。相关阅读凌晨2点生产库CPU飙到90%：一次PostgreSQL慢查询引发的雪崩复盘Docker 容器频繁 OOMKilled？我用一套监控脚本揪出内存泄漏的元凶。
2026-04-09 15:36:17
353
原创 上线前没人告诉我的事：Nginx 限流一旦配错，正常流量也会被自己打死
这个坑看似低级，但绝不是个例。在 Kubernetes、Service Mesh 大行其道的今天，"客户端 IP"的概念变得越来越复杂。Sidecar、Ingress、负载均衡器……每一层都可能改变请求的来源标识。限流之前，先搞清楚你限的是谁。如果你也遇到过类似的限流坑，欢迎在评论区分享。踩过的坑，都是宝贵的经验。# 查看当前 Nginx 限流配置# 实时监控限流日志# 测试限流是否生效# 查看当前连接状态。
2026-04-09 09:38:29
309
原创 上线前没人告诉我的事：Nginx 限流一旦配错，正常流量也会被自己打死
网关策略一旦脱离真实业务流量模型，再漂亮的配置也可能变成生产事故的导火索。Nginx 限流不是不能用，相反，它非常有用。但前提是你得知道自己在保护什么、牺牲什么、以及一旦误伤时怎么快速止血。如果你最近正准备给接口补限流，我建议先别急着抄配置。先把日志字段补齐，把热点接口拆开，把回滚动作写好。这样真出问题时，你救的不是配置文件，而是整条业务链路。
2026-04-08 09:40:04
357
原创 凌晨2点生产库CPU飙到90%：一次PostgreSQL慢查询引发的雪崩复盘
这条报表查询是我们运营后台用的，平时白天跑得挺快，怎么凌晨就出事了？查了一下调度日志，发现是定时任务在搞鬼。有个数据同步任务，凌晨1点半把orders表的一批历史数据更新了一下，触发了AUTOVACUUM。但就在VACUUM还没跑完的时候，另一个定时报表任务启动了——用的是旧缓存的执行计划。PostgreSQL的查询计划缓存机制，在某些情况下会"走错路"。当表的数据分布发生剧烈变化（比如大批量更新），之前的执行计划可能就不适用了，但数据库还在按老计划执行，结果就是全表扫描。
2026-04-05 15:36:59
381
原创 MySQL死锁排查实战：我如何用SHOW ENGINE INNODB STATUS揪出隐藏的资源竞争
MySQL选择回滚事务2，牺牲它来解除死锁。事务1得以继续执行。那次凌晨的死锁事件，最后发现是我们新上线的一个功能导致的。那个功能里有两个并发任务，分别更新了两张关联表，但更新的顺序正好相反。我花了3个小时排查，最后只改了一行代码——把两个任务的更新顺序统一了。但如果不理解死锁的原理，我可能还在到处加索引、调参数。死锁不可怕，可怕的是不知道怎么排查。希望这篇文章能帮到你。如果你也踩过类似的坑，欢迎在评论区交流。
2026-04-04 15:40:19
382
原创 MySQL 慢查询拖垮业务？我用一套诊断脚本把罪魁祸首定位到字段级别
MySQL 慢查询排查，最怕的就是凭经验猜。有了这套脚本，至少能把排查范围缩小到表和字段级别，不再大海捞针。当然，脚本只是工具，真正解决问题还得理解业务场景。就像这次，如果我不了解订单表的访问模式，即使脚本给出了字段建议，我也无法判断联合索引的字段顺序。运维这活儿，工具加经验，缺一不可。附：完整脚本地址以上脚本已整理到 GitHub，包含更完善的错误处理和注释：（注：脚本中的正则匹配是简化版，生产环境建议使用成熟的 SQL 解析库如sqlparse。
2026-04-04 09:34:06
351
原创 MySQL 慢查询拖垮业务？我用一行脚本实现秒级定位与自动化分析
MySQL慢查询排查，说难不难，说简单也不简单。把慢查询找出来- 靠脚本自动化，别肉眼翻日志把索引加上去- 用EXPLAIN验证，别凭感觉这套脚本我已经用了半年，处理了十几次线上性能问题。代码我放GitHub了，有需要自取。如果你也有MySQL性能优化的踩坑经历，欢迎在评论区交流。P.S. 下次遇到数据库CPU飙升，先别慌，跑一下脚本，30秒就知道是不是慢查询在搞鬼了。
2026-04-03 09:35:25
217
原创 压测对比报告：Node.js / Go / Rust 在高频API网关中的吞吐量与内存表现（附可复现脚本）
"选什么语言写 API 网关？"这个问题在团队扩规模时总会出现。本文用同一套压测脚本，对 Node.js、Go、Rust 三种技术栈做了完整的量化对比，所有脚本均可复现。
2026-03-28 09:38:15
235
原创 Docker 容器频繁 OOMKilled？我用一套监控脚本揪出内存泄漏的元凶
OOMKilled 多数时候不是突然发生的，而是一个渐变的过程。如果你没有监控，看到的就是"突然挂了"；但如果你有持续的内存采样，就能清楚地看到那条上升曲线，在它到达 limit 之前处理掉。我用的这两套脚本已经放到 GitHub 上了，有需要可以直接拿去改。有问题评论区见。Docker, OOMKilled, 内存泄漏, 监控, 运维, 脚本, 故障排查。
2026-03-27 15:40:21
377
原创 一次慢 SQL 不是数据库的锅：我怎么用 EXPLAIN 和采样日志定位真正瓶颈
数据库健康 ≠ SQL 没问题：数据库层指标正常，不代表 SQL 执行计划没走歪。EXPLAIN ANALYZE 是你的第一把刀。索引顺序决定执行计划：复合索引的列顺序会直接影响 MySQL 的执行路径。（created_at, status）和（status, created_at）在这种场景下性能差距是 60 倍。采样日志比 slow query 更准：slow query log 告诉你哪些 SQL 慢，但采样查询告诉你为什么慢、数据分布是什么，两者结合才是完整的诊断闭环。
2026-03-26 15:42:20
369
原创 上线前没人告诉我的事：Nginx 限流一旦配错，正常流量也会被自己打死
检查项操作测试不同网络环境用手机 4G、办公室 WiFi、公司 VPN 都要测一遍模拟浏览器预加载Chrome DevTools Network 面板限制"Disable cache"后刷新确认 burst 值burst 要能覆盖正常页面的并发请求数检查多层叠加确认 Nginx + Gateway + 应用三层限流不会互相冲突设置合理的告警限流拒绝率 > 1% 就应该告警，而不是等用户投诉上线后观察 30 分钟限流的效果往往需要积累一段时间才能暴露。
2026-03-26 09:37:21
324
原创 上线前没人告诉我的事：Nginx 限流一旦配错，正常流量也会被自己打死
检查项操作测试不同网络环境用手机 4G、办公室 WiFi、公司 VPN 都要测一遍模拟浏览器预加载Chrome DevTools Network 面板限制"Disable cache"后刷新确认 burst 值burst 要能覆盖正常页面的并发请求数检查多层叠加确认 Nginx + Gateway + 应用三层限流不会互相冲突设置合理的告警限流拒绝率 > 1% 就应该告警，而不是等用户投诉上线后观察 30 分钟限流的效果往往需要积累一段时间才能暴露。
2026-03-24 15:34:15
365
原创 上线前没人告诉我的事：Nginx 限流一旦配错，正常流量也会被自己打死
检查项操作测试不同网络环境用手机 4G、办公室 WiFi、公司 VPN 都要测一遍模拟浏览器预加载Chrome DevTools Network 面板限制"Disable cache"后刷新确认 burst 值burst 要能覆盖正常页面的并发请求数检查多层叠加确认 Nginx + Gateway + 应用三层限流不会互相冲突设置合理的告警限流拒绝率 > 1% 就应该告警，而不是等用户投诉上线后观察 30 分钟限流的效果往往需要积累一段时间才能暴露。
2026-03-24 09:40:46
408
原创 从零搭建 Kubernetes 集群网络异常排查脚本：Pod 跨节点通信失败的一键诊断
Pod 跨节点通信问题的根因排查，核心在于"分层定位"：从下往上逐层排除，脚本的价值在于把这个过程标准化、可复现化。下次告警来的时候，不需要 15 分钟手动排查，运行脚本 2 分钟拿到结论，修不修再看具体情况。脚本我已经放在生产集群验证过了，有需要的同学可以直接拿过去改改标签和阈值用，有问题欢迎评论区交流。
2026-03-22 15:44:21
408
原创 Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了
这次故障前后折腾了将近 2 小时，其中大部分时间在"猜"问题在哪。事后我整理了这套脚本，下次遇到类似情况，5 分钟内就能定位根因。说白了，Rebalance 多数时候不是 Kafka 的问题，而是消费者端的代码问题。要么是处理太慢，要么是心跳没跟上。如果你也在被 Rebalance 困扰，先跑一下上面的脚本，看看是哪种情况。多数时候，答案就在日志里。
2026-03-22 09:34:33
303
原创 Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了
说实话，这次排查让我对「可观测性」有了更深的体会。之前总觉得可观测就是装个 Prometheus、搭个 Grafana。但真正遇到问题才发现，光有指标是不够的——你需要的是把分散的数据串起来看的能力。Rebalance 这类问题特别适合用关联分析来定位，因为它的根因往往不在 Kafka 本身，而在外部（网络、GC、资源竞争）。如果你也在被类似问题困扰，不妨先跑一下这套脚本，看看能不能找到线索。有踩坑经历的老铁，欢迎评论区交流。相关工具 & 命令— 采集消费者组状态kafkacat— 查看消费延迟。
2026-03-21 15:34:45
311
原创 Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了
Kafka 消费者组 Rebalance 不是洪水猛兽，但它是一个信号——系统在告诉你：要么配置不对，要么消费逻辑有问题。与其等 Rebalance 搞垮了服务再去救火，不如提前用脚本把消费者组的健康状态监控起来。毕竟，可观测性才是 SRE 的第一道防线。如果你也在被 Rebalance 困扰，先把上面的脚本跑起来，看看 member 数和 assigned partitions 是不是在抖——问题往往就这么简单。🐾。
2026-03-21 09:34:50
379
原创 Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了
Rebalance 本身不是错，频繁 Rebalance 才是问题。把 Rebalance 当成一种“可观测事件”去采集和归因先用脚本拉证据链，再决定要不要改参数如果你愿意，把你看到的日志关键词（打码后也行）贴出来，我可以帮你按上面的分类快速判断最像哪一类。
2026-03-20 15:33:30
427
原创 Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了
如果你最近也遇到消费者组反复 Rebalance，别急着扩机器，也别第一时间重启。先把现场留住，把 lag、rebalance、消费耗时这三条线对起来看。很多时候，根因就藏在你自己那段“顺手写的同步调用”里。消息队列最怕的不是流量大，而是消费端装作自己很轻，实际上每条消息都背着一块石头在跑。如果你愿意，我下次可以把我现在用的 Kafka 值班 Runbook 再展开写成一版更完整的清单。
2026-03-18 15:37:31
416
原创 性能对比与基准测试实战：如何科学衡量 Redis 的吞吐与延迟
基准测试不是跑一次就完事的——它是持续优化的基石。上线新功能前扩容 Redis 规格后重大代码重构后常规性能巡检别像当年的我一样，用"感觉"来做性能决策。跑一下基准测试，让数据说话，你会发现很多"想当然"的优化其实方向都错了。记住：没有度量的优化，就是盲人摸象。题图：科学测试，让 Redis 性能不再靠猜。
2026-03-17 15:35:12
361
原创 血泪教训！MySQL索引我踩过的5个坑（附生产级解决方案）
大家好，我是小柚。。说出来你们可能不信，我第一次在生产环境遇到索引失效问题时，硬是排查了整整3天。明明给status和都建了索引，为什么查询还是跑了3秒？DBA同事瞄了一眼，淡定地说：“你用函数包裹了索引列，索引当然失效了。那一刻我意识到，MySQL索引失效的坑，远比我想象的深。今天就把我踩过的5个致命坑全部分享出来，每个坑都附带完整的复现场景、原因分析和可运行的代码示例。坑号场景原因解决方案1索引列使用函数改为范围查询2隐式类型转换确保类型一致3索引列参与运算运算移到常量侧4。
2026-03-15 21:11:53
141
原创 血泪教训！MySQL索引我踩过的5个坑（附生产级解决方案）
大家好，我是小柚。。说出来你们可能不信，我第一次在生产环境遇到索引失效问题时，硬是排查了整整3天。明明给status和都建了索引，为什么查询还是跑了3秒？DBA同事瞄了一眼，淡定地说：“你用函数包裹了索引列，索引当然失效了。那一刻我意识到，MySQL索引失效的坑，远比我想象的深。今天就把我踩过的5个致命坑全部分享出来，每个坑都附带完整的复现场景、原因分析和可运行的代码示例。坑号场景原因解决方案1索引列使用函数改为范围查询2隐式类型转换确保类型一致3索引列参与运算运算移到常量侧4。
2026-03-15 20:21:14
168
原创 血泪教训！MySQL索引我踩过的5个坑（附生产级解决方案）
大家好，我是小柚。。说出来你们可能不信，我第一次在生产环境遇到索引失效问题时，硬是排查了整整3天。明明给status和都建了索引，为什么查询还是跑了3秒？DBA同事瞄了一眼，淡定地说：“你用函数包裹了索引列，索引当然失效了。那一刻我意识到，MySQL索引失效的坑，远比我想象的深。今天就把我踩过的5个致命坑全部分享出来，每个坑都附带完整的复现场景、原因分析和可运行的代码示例。坑号场景原因解决方案1索引列使用函数改为范围查询2隐式类型转换确保类型一致3索引列参与运算运算移到常量侧4。
2026-03-15 20:06:42
308
原创 血泪教训！MySQL索引我踩过的5个坑（附生产级解决方案）
大家好，我是小柚。。说出来你们可能不信，我第一次在生产环境遇到索引失效问题时，硬是排查了整整3天。明明给status和都建了索引，为什么查询还是跑了3秒？DBA同事瞄了一眼，淡定地说：“你用函数包裹了索引列，索引当然失效了。那一刻我意识到，MySQL索引失效的坑，远比我想象的深。今天就把我踩过的5个致命坑全部分享出来，每个坑都附带完整的复现场景、原因分析和可运行的代码示例。坑号场景原因解决方案1索引列使用函数改为范围查询2隐式类型转换确保类型一致3索引列参与运算运算移到常量侧4。
2026-03-15 19:54:13
277
原创 血泪教训！MySQL索引我踩过的5个坑（附生产级解决方案）
大家好，我是小柚。。说出来你们可能不信，我第一次在生产环境遇到索引失效问题时，硬是排查了整整3天。明明给status和都建了索引，为什么查询还是跑了3秒？DBA同事瞄了一眼，淡定地说：“你用函数包裹了索引列，索引当然失效了。那一刻我意识到，MySQL索引失效的坑，远比我想象的深。今天就把我踩过的5个致命坑全部分享出来，每个坑都附带完整的复现场景、原因分析和可运行的代码示例。坑号场景原因解决方案1索引列使用函数改为范围查询2隐式类型转换确保类型一致3索引列参与运算运算移到常量侧4。
2026-03-15 18:59:49
322
原创 构建以观测为先的 Redis 容错体系：当缓存失效时如何不被业务拖垮
把注意力从“单点技巧”转到“可观测 + 自动化缓解 + 运行手册”，你会发现许多看似无法预防的缓存事故，可以在可控范围内被探测并快速缓解。代码层面的优化（布隆过滤器、Lua、Redisson）仍然重要，但唯有成为一个可被测量、可被自动响应的体系，才能在高并发的真实世界中存活。如果你同意，我可以将这份改写稿同步到/tmp并用 csdn-publisher 的流程提交草稿（或先再做一次字数/风格微调）。要我现在替换现有稿件、还是先保持原稿并另外保存为备用稿？
2026-03-15 17:53:08
390
原创 Redis 缓存失效与分布式锁实战踩坑：我被这些问题坑了3次后终于搞懂了
缓存雪崩→ 随机过期时间 + 预热 + 降级方案缓存穿透→ 缓存空值 + 布隆过滤器缓存击穿→ 分布式锁 + 双重检查分布式锁失效→ 使用 Redisson + 正确释放数据结构选用错误→ 根据场景选择合适的数据结构Redis 是后端开发中最常用的中间件之一，但其中的坑也非常多。希望我的血泪教训能帮你少走弯路。你遇到过哪些 Redis 踩坑经历？欢迎在评论区分享，大家一起避坑！我是 [二白同学]，会持续分享实战开发干货。
2026-03-15 15:36:21
337
原创 MySQL 索引失效与慢查询优化：我被这些SQL坑了3次后总结的保命指南
索引列上不要做函数操作- 会导致索引失效字符串比较要加引号- 避免隐式类型转换模糊查询%放右边- 遵循最左前缀原则复合索引要按顺序使用- 从左到右依次使用OR两边都要有索引- 否则全表扫描永远用 EXPLAIN 分析你的SQL，不要凭感觉判断索引是否生效。MySQL优化器有时候的选择可能和你想的不一样。有什么问题也欢迎在评论区留言讨论！延伸思考：索引优化只是SQL优化的一部分，除了索引，还需要注意什么？避免 SELECT *，只查询需要的字段合理使用覆盖索引，避免回表。
2026-03-15 09:34:26
392
基于SpringBoot的在线网盘系统｜课程设计源码分享
2025-05-16
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人