在MySQL排查性能问题时，查询慢日志是定位SQL瓶颈最直接的手段，本文基于iapp连接MySQL数据库的常见场景，给出从开启慢日志到分析结果的全流程操作指南，确保你能够快速找到拖慢数据库的元凶。
为什么优先排查慢日志数据库性能瓶颈的第一线索
当你在iapp中遇到接口响应慢或页面加载卡顿，多数情况下罪魁祸首就是慢查询，MySQL慢日志记录了执行时间超过预设阈值的SQL语句,是DBA和开发人员最常用的性能诊断工具。
行业共识：在排查数据库性能问题时，至少有80%的优化空间来自慢日志分析，相比直接查看进程列表或使用EXPLAIN，慢日志能提供历史数据,帮助你发现偶发性的性能问题。
如果你在iapp的数据查询中频繁出现超时，第一步不是改代码，而是先确认慢日志是否开启,以及日志里记录了哪些SQL。
iapp查询mysql数据库慢日志的完整准备流程
在iapp环境下查询慢日志，需要先确保MySQL服务器端正确配置,以下步骤假设你有数据库服务器的操作系统或管理工具权限。
确认当前慢日志状态
登录MySQL,执行：
SHOW VARIABLES LIKE 'slow_query_log%';如果slow_query_log值为OFF，说明未开启，同时查看slow_query_log_file字段,确认日志文件路径。
开启慢查询日志并设置阈值
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2; -- 超过2秒的记录（单位秒）
SET GLOBAL log_queries_not_using_indexes = ON; -- 记录未使用索引的查询long_query_time建议从2秒开始，如果业务压力大，可以先设为5秒，再逐步调低。log_queries_not_using_indexes会记录所有全表扫描的SQL，即使它们很快,这有助于发现潜在索引问题。
注意：上述设置重启MySQL后会失效，如需永久生效，需要修改配置文件
my.cnf或my.ini，在[mysqld]段加入：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = 1让iapp连接生效
配置完成后，iapp无需任何改动，因为它只是客户端，慢日志由MySQL服务器端记录，所有通过iapp发起的查询都会被监控，你只需确保iapp使用的数据库账户有权限执行慢查询相关命令（如SHOW VARIABLES）,但一般不需要额外授权。
查询数据库慢日志（MySQL）的两种实用方法
有两种主流方式,适合不同场景。
直接查看慢日志文件
如果服务器上可以访问文件系统,直接查看日志文件最直观。
sudo tail -100 /var/log/mysql/slow.log每一段慢日志包含：
# Time: 2026-01-15T10:30:00.123456Z执行时间# User@Host: root[root] @ localhost [] Id: 123连接信息# Query_time: 2.567790 Lock_time: 0.000123 Rows_sent: 10 Rows_examined: 1000关键指标SET timestamp=...执行时间戳SELECT ...具体的SQL语句
核心指标解读：
Query_time：SQL实际执行时间（秒）,超过阈值才会记录。Lock_time：等待锁的时间,过高可能表示锁竞争。Rows_examined：扫描行数，远大于Rows_sent时说明索引效率低。
通过系统表查询
从MySQL 5.6开始，可以直接查询系统表获取慢日志,无需文件权限。
USE mysql;
SELECT FROM slow_log ORDER BY start_time DESC LIMIT 10;如果报错，说明表未启用，需要先开启log_output为TABLE：
SET GLOBAL log_output = 'TABLE';
此时慢日志会写入mysql.slow_log表，可以像普通表一样查询、排序、筛选。注意：该表是CSV引擎，写入性能较低，线上环境建议优先使用文件方式,分析时再导入表。
| 对比维度 | 文件方式 | 表方式 |
|---|---|---|
| 实时性 | 立即写入，可tail | 立即写入，但查询需SQL |
| 筛选能力 | 需配合grep或工具 | 可直接用WHERE条件 |
| 性能影响 | 极低 | 对写操作有轻微影响 |
| 适用场景 | 生产环境，日志量大 | 开发测试或临时分析 |
用mysqldumpslow分析慢日志的实战经验
原始日志文件堆积很快，手动分析效率低，MySQL自带的mysqldumpslow工具是分析慢日志的利器，支持按平均查询时间、访问次数、锁时间等排序。
安装与基本用法
mysqldumpslow随MySQL安装包一起提供，位于安装目录的bin或scripts下,使用前确认环境变量。
常用命令：
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log-s c：按查询次数排序（c：count，t：time，l：lock time，at：平均时间）-t 10：只显示前10条
按查询时间排序锁定最慢SQL
mysqldumpslow -s t -t 5 /var/log/mysql/slow.log输出会将相似的SQL（参数不同）归并为一组，用N表示参数个数。
Count: 100 Time=2.50s (250s) Lock=0.01s (1s) Rows=100.0 (10000), root[root]@localhost
SELECT FROM orders WHERE status = N AND create_time > N这里Count: 100表示该模式执行了100次，总时间250秒，平均2.5秒。
N代表参数占位符。
分析结果指导优化
- 如果
Rows_examined远大于Rows_sent,说明需要优化索引或改写SQL。 - 如果
Lock_time占比高,检查是否有长事务或锁等待。 - 如果一条SQL出现次数多且平均时间高,优先优化它。
对于iapp场景，如果查询列表接口频繁出现慢日志，可以结合EXPLAIN分析执行计划,通常添加覆盖索引或调整分页逻辑就能优化。
查询数据库慢日志（MySQL）的常见问题
慢日志文件在哪里？如何确认路径？
执行SHOW VARIABLES LIKE 'slow_query_log_file';可直接得到路径，默认在MySQL数据目录下，文件名为主机名-slow.log，如果未设置,手动指定路径时确保MySQL用户有写权限。
如何只记录特定类型的慢查询？
通过log_queries_not_using_indexes和long_query_time组合控制，如果想排除某些库或表，可以在MySQL 5.7.8之后使用log_slow_extra或借助init_connect配合SET SESSION long_query_time，但更实用的方法是定期清理日志,避免混入过多无关查询。
慢日志文件太大怎么办？
慢日志会累积庞大，建议启用日志轮转或定期归档，在Linux下可以使用logrotate服务，配置/etc/logrotate.d/mysql，按照天或大小切割，如果不需要长期保留，直接truncate或删除后重新创建（需重启MySQL或执行FLUSH SLOW LOGS）。注意：不要在生产环境随意删除日志文件,以免导致MySQL报错。
慢日志是数据库性能优化的第一步，也是最重要的一步，通过本文介绍的启用、查看、分析流程，你完全可以在iapp连接MySQL的场景下，快速定位那些拖慢响应的SQL,并制定针对性的优化方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/iapp%e6%9f%a5%e8%af%a2mysql%e6%95%b0%e6%8d%ae%e5%ba%93_%e6%9f%a5%e8%af%a2%e6%95%b0%e6%8d%ae%e5%ba%93%e6%85%a2%e6%97%a5%e5%bf%97%ef%bc%88mysql%ef%bc%89/
