升级后需检查慢查询日志配置是否启用，确认slow_query_log为ON，设置long_query_time阈值并开启log_queries_not_using_indexes以捕获未使用索引的查询，通过mysqldumpslow或pt-query-digest分析日志中Query_time和Rows_examined较高的SQL，及时发现性能问题。
MySQL升级后，检查慢查询是确保数据库性能稳定的关键步骤。重点在于确认慢查询日志的配置状态，并利用工具分析历史或实时的慢查询记录。
确认慢查询日志是否启用
升级后配置可能重置，需手动验证：
- 登录MySQL，执行 SHOW VARIABLES LIKE 'slow_query_log'; 查看值是否为 ON。若为 OFF，则日志未开启。
- 检查日志文件路径：SHOW VARIABLES LIKE 'slow_query_log_file'; 确认日志输出位置，便于后续查看。
- 查看阈值设置：SHOW VARIABLES LIKE 'long_query_time'; 默认10秒，通常建议调整为1-2秒以捕获更多潜在问题。
- 建议在 my.cnf 配置文件中永久设置 slow_query_log=ON 和 long_query_time=2，避免重启失效。
检查未使用索引的查询
这类查询极易成为性能隐患，即使执行时间未超阈值也应关注：
- 执行 SHOW VARIABLES LIKE 'log_queries_not_using_indexes';
- 如果结果为 ON，且 slow_query_log 也开启，则所有未走索引的查询都会被记录到慢查询日志中，方便排查。
- 此选项在高并发场景下会产生大量日志，测试环境可开启，生产环境需权衡利弊。
分析慢查询日志内容
确认日志开启并运行一段时间后，即可分析日志找出问题SQL：
- 使用MySQL自带的 mysqldumpslow 工具汇总分析，例如：mysqldumpslow -s t -t 10 /var/lib/mysql/localhost-slow.log 可列出执行时间最长的10条SQL。
- 更强大的第三方工具如 pt-query-digest（Percona Toolkit），能生成更详细的报告，精准定位最耗资源的查询。
- 直接查看日志文件，关注 Query_time 和 Rows_examined 字段，数值越大代表消耗越高，优化优先级也越高。
