大促期间才出现的慢查询，往往不是平时没有，而是平时并发低、数据量小，问题被掩盖了。定位这类问题，核心思路是拿到“当时的真实执行现场”，而不是靠事后猜测。常见的技术路线有三条：慢查询日志分析、执行计划与统计信息推演、运行中实时采样。它们各有代价，需要按场景选择。需要具体实施方案时，可以参考我们的软件定制开发与系统集成服务，或浏览同类项目案例了解落地方式。
方案一：慢查询日志——适合先摸清“哪些语句变慢”
慢查询日志是最基础也最不容易被绕过的手段。它记录超过时间阈值的语句，配合日志分析工具可以按耗时、调用次数、扫描行数排序，适合在大促前后快速圈定嫌疑对象。
优点是采集成本低、对业务侵入小，历史数据可回看；缺点是阈值设置需要经验，阈值定高了漏掉问题语句，定低了日志量过大反而影响排查效率。此外，日志通常只记录执行时间，不直接告诉你为什么慢。
- 优点：开启简单，能覆盖所有连接到实例的语句，事后可复盘。
- 缺点：需要合理设置阈值和采样策略，日志量大时分析成本高；对“偶发但致命”的语句可能抓不全。
- 适用边界：大促前压测与预演阶段建立基线，大促后快速回溯；不能替代执行计划分析。
建议在压测环境把阈值调低一档做全量采集，生产环境按业务时段和实例规格设置相对宽松的阈值，并保留足够长的日志周期。
方案二：执行计划与统计信息分析——适合判断“为什么这条语句变慢”
拿到慢语句之后，看执行计划是进一步定位的关键。重点观察访问路径是否走索引、预估行数与实际行数偏差、连接顺序是否合理，这些信息能解释大促期间数据分布变化带来的性能波动。
代价在于执行计划受统计信息、参数取值和数据库版本影响，同一语句在不同参数下可能选择不同计划，需要结合具体场景验证。另外，生产环境直接执行 EXPLAIN 一般是安全的，但带实际执行的诊断要谨慎。
- 优点：能直接定位索引缺失、统计信息过期、连接顺序不当等根因，指导优化方向明确。
- 缺点：需要一定的数据库功底；统计信息不准时结论可能失真；参数敏感语句要专门做绑定变量分析。
- 适用边界：语句相对固定、慢查询集中在少数几条核心 SQL 的场景；对动态拼接 SQL 较多的系统，需要先做语句归一化。
实务中建议先在压测环境用真实数据量复现，再对比大促前后执行计划的变化。团队如果缺少专职 DBA，可以把这一步纳入上线验收环节。
方案三：运行中实时采样——适合排查“无法复现的偶发卡顿”
当慢查询日志和执行计划都无法解释时，可以在大促期间对数据库连接和语句做实时采样，例如周期性抓取正在执行的语句、等待事件和锁信息，拼出问题发生时间点的现场快照。
这类手段更贴近真实负载，但采样本身有开销，采样频率和范围要控制。它通常作为补充手段，而不是第一选择。
- 优点：能捕捉瞬时并发、锁等待、连接池耗尽等日志难以还原的现场。
- 缺点：需要提前部署采集机制；采样有性能开销；数据解读门槛较高。
- 适用边界：问题偶发、难以在压测中复现，且已有一定监控基础的系统。
如果团队运维力量有限，更稳妥的做法是把采样能力放在云数据库自带的监控里，避免自行开发采集脚本引入额外风险。涉及云部署与运维的细节，可参考我们的服务范围与交付流程。
什么情况下不要选某种方案
选型不仅要看优点，更要看边界。以下情况建议避开对应方案：
- 不要只依赖慢查询日志：当问题表现为连接数打满、锁等待严重而非单条语句超时时，日志可能抓不到关键信息，需要结合实时采样和监控指标。
- 不要在业务高峰直接做重量级执行计划诊断：带实际执行的诊断语句可能加重负载，应放在低峰期或影子库进行。
- 不要在缺乏监控基线时贸然上实时采样：没有基线数据，采样结果很难判断是否异常，反而增加误判风险。
决策建议与文字版对比清单
实际排查通常不是三选一，而是按顺序组合：先用慢查询日志圈定范围，再用执行计划找根因，最后用实时采样补现场。大促前应完成一轮压测基线，并确认慢日志与监控已开启。
下面给出文字版对比清单，便于团队快速对照：
- 慢查询日志 → 适合：需要快速圈定嫌疑语句、做历史回溯的团队 → 主要代价：阈值调优与日志分析工作量。
- 执行计划分析 → 适合：语句相对固定、有数据库功底的团队 → 主要代价：统计信息与参数敏感性带来结论不确定性。
- 实时采样 → 适合：偶发难复现、已有监控基础的系统 → 主要代价：采集开销与解读门槛。
如果系统涉及多个业务系统与数据库实例，建议把慢查询治理纳入日常运维交接内容。我们做过的同类项目可参考，具体做法视系统规模而定。
自查清单
- 大促前是否完成压测并建立慢查询基线？
- 慢查询日志的阈值、保留周期是否按业务时段设置？
- 核心 SQL 是否做过执行计划审查，统计信息是否定期更新？
- 是否准备了低峰期或影子库用于执行计划验证？
- 实时采样机制是否提前部署并验证过开销？
- 问题定位后是否形成索引调整或语句优化，并回归验证？
慢查询定位不是一次性的工作，建议把上述检查项固化到上线验收流程中。需要进一步讨论具体场景，欢迎联系我们。
