升级后需开启慢查询日志并设置阈值，如MySQL中配置slow_query_log和long_query_time；2. 使用SHOW PROCESSLIST和sys.statement_analysis实时诊断执行中的慢查询；3. 通过mysqldumpslow或pt-query-digest分析日志，定位高频、高耗时或未用索引的SQL；4. 持续监控以发现性能回归问题。
监控以发现性能回归问题。系统或数据库升级后，检查慢查询是确保性能稳定的关键步骤。核心思路是先开启监控，再分析数据，最后定位问题。
启用慢查询日志
这是获取慢查询信息最直接的方式。需要确认数据库的慢查询日志功能已开启，并根据实际情况调整阈值。
- MySQL：检查配置文件（如my.cnf）中slow_query_log=ON，设置long_query_time（例如0.5秒），并指定日志路径slow_query_log_file。可开启log_queries_not_using_indexes=ON来捕获未使用索引的查询。
- 其他数据库：参照对应数据库文档，启用等效的慢查询或执行日志功能。
使用实时诊断工具
在不重启服务的情况下，快速查看当前正在执行的查询状态。
- 执行SHOW PROCESSLIST\G命令，关注Time列耗时较长的查询和State列处于“Sending data”、“Copying to tmp table”等状态的SQL。
- 查询sys.statement_analysis视图，按总延迟排序，找出消耗资源最多的规范化SQL语句。
分析日志定位问题SQL
利用专业工具解析慢查询日志，找出需要优化的目标。
- 使用mysqldumpslow命令行工具汇总日志，例如mysqldumpslow -s at -t 10 slow.log可列出平均执行时间最长的10条SQL。
- 使用pt-query-digest（Percona Toolkit）进行深度分析，它能提供详细的统计报告和查询建议。
- 重点关注执行次数多、总耗时长、扫描行数多或未使用索引的查询。
