慢查询指执行时间超过long_query_time阈值的SQL语句，需slow_query_log开启才记录，包含完整SQL、耗时、锁等待等字段，不区分语句类型；默认10秒不适用现代业务，通常设为0.5～2秒。
慢查询指的是执行时间超过预设阈值的 SQL 语句。这个阈值由 MySQL 的 long_query_time 参数控制，默认是 10 秒，但生产环境中通常设为 1～2 秒——只要查询耗时超过该值，就会被记录进慢查询日志。
慢查询的核心特征
它不是“看起来慢”，而是有明确判定标准的可量化行为：
- 触发条件严格依赖 实际执行耗时，与返回行数、数据量大小无直接关系（哪怕只查 1 行，若扫描全表+没索引，也可能超时）
- 必须在 slow_query_log = ON 开启状态下才记录，且日志默认关闭，需手动启用
- 记录内容包含完整 SQL 文本、执行时间、锁等待时间、扫描行数、返回行数等关键诊断字段
- 不区分 SELECT/UPDATE/DELETE/INSERT —— 只要执行时间超标，都算慢查询
为什么 10 秒默认值在现实中基本不用
现代业务系统对响应延迟敏感，用户等待超过 1 秒就可能流失。所以：
- 电商搜索、支付确认、实时消息等场景常设为 0.5～1 秒
- 后台报表类任务可放宽至 5～10 秒，但仍建议单独归类，不混入在线服务慢日志
- 阈值过大会漏掉大量中等耗时但高频的低效查询，它们累积起来对性能伤害更大
慢查询 ≠ SQL 写得差，但它是优化入口
一条语句变慢，可能是多种因素叠加的结果：
- 索引失效（如对字段做函数操作：
WHERE YEAR(create_time) = 2024） - 统计信息过期，优化器选错执行计划
- 大表 JOIN 未加驱动表提示或缺少关联字段索引
- 高并发下锁等待加剧，实际执行时间被动拉长
- 磁盘 I/O 瓶颈（尤其机械盘 + 大量临时表排序）
识别慢查询只是第一步，后续要用 EXPLAIN 看执行计划、用 pt-query-digest 聚类分析、结合 show profile 或 performance_schema 定位耗时环节。不复杂但容易忽略。
