MySQL 慢查询怎么查？慢日志、执行计划与优化验证
网站接口慢时，数据库可能是原因之一，但应用排队、网络和外部 API 也会消耗时间。先用应用日志确认数据库调用占比，再进入慢查询排查。本文针对 MySQL 8.4，所有诊断都应在获授权范围内进行，日志和查询样本需要保护业务数据。
先检查已有日志设置
在受控管理会话中查看当前配置：
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_output';
确认日志是否启用、输出到哪里、阈值是多少，并核对磁盘空间与保留安排。已有监控或数据库平台负责采集时，优先使用既有入口，不要重复开启大量日志。慢日志与一般查询日志不是同一个功能，不能为了找慢请求记录全部业务活动。
需要临时调整时先保存原值，选择有限观察窗口。阈值过低可能产生大量文件，SQL 中还可能包含用户数据或令牌。配置与记录条件可查MySQL 慢查询日志文档。
注意会话阈值与连接池
某些配置同时有全局值与会话值。调整全局慢查询阈值后，已有应用连接未必立即采用新值，连接池中的旧会话可能继续使用原设置。应核对实际测试连接，而不是因为短时间没有日志就认定数据库不慢。
不要为了刷新设置在高峰期同时断开所有连接。按应用正常连接维护方式安排验证，并把采样时段与业务高峰对应起来。日志数量变化也可能只是阈值改变，不能直接解释为系统性能突然变差。
按总影响筛选值得处理的查询
把同类 SQL 按结构归类，比较执行次数、总耗时、返回行数和扫描量。某条偶尔执行的报表很慢，不一定比每秒运行数百次的中等耗时查询更值得优先处理。还要结合用户等待和系统资源，确定优化目标。
为选中的查询保留脱敏样本、参数分布、相关表规模和索引信息。不要只拿一个恰好命中少量数据的参数代表所有用户；热点账号、大范围日期和空结果都可能走不同路径。
用执行计划提出假设
可以先对已经确认的只读 SELECT 查看普通 EXPLAIN，观察访问方式、连接顺序、预估行数和索引使用。不要只看到某个关键词就下结论，估计值需要结合实际数据分布解释。
EXPLAIN ANALYZE 会实际执行受支持的语句来收集运行信息，因此必须评估查询成本，在受控环境或合适时段使用，不能当成完全无影响的静态检查。MySQL EXPLAIN 文档
新索引会占用空间并影响写入，结构变更也可能带来锁和资源开销。先在接近真实数据规模的测试环境验证，再安排上线。优化目标可能是缩小结果集、调整查询或避免重复调用，并不总是增加索引。
对照同一业务样本验收
修改前后比较相近负载下的查询分布、接口响应和错误率，检查其他查询与写入是否受影响。缓存冷热不同会显著影响结果，应注明测试条件，不能用一次快响应宣布优化完成。
保留原查询或结构变更的回退安排，并确认回退本身的操作成本。观察结束后恢复不再需要的临时日志设置，继续保留长期有用的监控。把最终确认的原因、样本和收益记录下来，避免以后只剩一个无法解释的参数变化。