标签频道
SQL优化
该标签下的文章、提问与讨论帖。
SQL执行计划漂移测试：测试环境断言用例与CI自动化监控清单 现象或背景 我做了10年测试开发，在2.3亿行级别的账务表上踩过一模一样的坑——凌晨批跑后白天的接口回归突然从5ms飙到12s，CI绿了但性能回归没人拦。下面从测试侧给你三个可落
现象或背景 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。 先给一个具体的数：我们库
现象或背景：SQL 执行计划漂移，但不是参数没调对 有一条 SQL，执行计划漂移了，导致 P99 从 15ms 飙到 3.4s，但索引没变、SQL 文本没变，连 buffer pool 命中率也没掉。这种「执行计划漂移」比绝大多数「索引没建
【背景】 做了 15 年 DBA，慢查询治理是日常中的日常。但每次拉上开发一起看 slow log，第一句话永远是"加个索引吧"。这句话听起来没毛病——5 分钟搞定、开发不用改代码、风险最低。 但问题是：这个"第一反应"在很多场景下是错的，
【背景】 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建索引本身成了事故」的场景。 先给一个具体的数：我们库里一
【背景】 做了 5 年 DBA，慢查询治理是每周的固定动作。但每次性能评审，团队都会撞上同一个问题："这条 SQL 慢，我们到底该干嘛？" 答案从来不是唯一的——改 SQL 写法、加索引、拆表分库、加缓存、换引擎……每条路都有成本，每条路都
«结论先行：在 800 万行用户行为日志上计算「连续活跃 ≥ N 天」标签，窗口函数（LAG + 行号差值法）P99 = 2.1s，自连接 P99 = 25.3s，临时表迭代 P99 = 18.7s——12 倍和 9 倍差距。但窗口函数方案
【背景】 做了 5 年大数据平台，80% 的工单是「这条 SQL 慢」。团队里有一个不成文的默认动作：先 EXPLAIN，看到 type=ALL 或 rows 很大，就加索引。我早期也这么干，直到去年一次「加完索引 P99 反而涨了 12%
做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。 我见过太多团队把"加索引"
文
标题
摘要