升级后需检查慢查询日志配置是否启用，确认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，避免重启失效。

检查未使用索引的查询

这类查询极易成为性能隐患，即使执行时间未超阈值也应关注：

有道翻译AI助手

有道翻译提供即时免费的中文、英语、日语、韩语、法语、德语、俄语、西班牙语、葡萄牙语、越南语、印尼语、意大利语、荷兰语、泰语全文翻译、网页翻译、文档翻译、PDF翻

70

查看详情

• 执行 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 字段，数值越大代表消耗越高，优化优先级也越高。

基本上就这些。升级后主动检查，能快速发现因配置丢失或执行计划变化导致的新性能问题。