MySQL慢查询日志是定位性能瓶颈最直接有效的手段，需合理配置long_query_time（建议0.5～2秒）、验证写入有效性，并通过mysqldumpslow或EXPLAIN分析优化。
MySQL慢查询日志是定位性能瓶颈最直接有效的手段之一。开启它不难，但关键在于配置合理、验证到位、日志可用——尤其要注意临时设置不持久和阈值设太大会漏掉真实慢SQL这两个常见坑。
确认当前状态并检查参数
登录MySQL后，先执行以下命令查看慢查询日志是否已启用及当前配置：
- SHOW VARIABLES LIKE 'slow_query_log'; —— 若返回 OFF，说明未开启
- SHOW VARIABLES LIKE 'slow_query_log_file'; —— 查看日志默认路径（如 /var/lib/mysql/hostname-slow.log）
- SHOW VARIABLES LIKE 'long_query_time'; —— 默认通常是10秒，生产环境建议调低到0.5～2秒
- SHOW VARIABLES LIKE 'log_queries_not_using_indexes'; —— 可选开启，用于捕获未走索引的查询
两种开启方式：临时生效 or 永久生效
临时开启适合测试或紧急排查，修改后立即生效但重启MySQL会丢失；永久开启需改配置文件，适合生产环境。
-
临时开启（无需重启）：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON'; -
永久开启（推荐）：
编辑 MySQL 配置文件（Linux 常为 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，Windows 为 my.ini），在 [mysqld] 段下添加：[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
log_output = FILE保存后重启 MySQL：systemctl restart mysql（或 mysqld）
CRMEB Min开源商城下载CRMEB Min是CRMEB品牌全新推出的一款轻量级、高性能、前后端分离的开源电商系统，完善的后台权限管理、会员管理、订单管理、产品管理、客服系统、CMS管理、多端管理、页面DIY、数据统计、系统配置、组合数据管理、日志管理、数据库管理，一键开通短信、产品采集、物流查询等接口，系统采用TP6+Mysql+Uniapp+iView+Redis+workerman+form-builder等最流行热
验证日志是否真正记录
不能只看变量值为 ON 就认为成功——必须实测写入。
- 执行一条“人工慢SQL”：SELECT SLEEP(2);（确保超过 long_query_time）
- 检查慢查询计数是否增加：SHOW GLOBAL STATUS LIKE 'Slow_queries';
- 直接查看日志文件：tail -f /var/log/mysql/slow.log（注意：MySQL 进程需对日志路径有写权限）
- 若用 log_output = TABLE，可查表：SELECT * FROM mysql.slow_log LIMIT 5;
后续分析与优化建议
日志有了，下一步才是重点：
- 用官方工具快速汇总：mysqldumpslow -s t -t 10 /var/log/mysql/slow.log（按耗时排序取前10条）
- 重点关注 Rows_examined（扫描行数）远大于 Rows_sent（返回行数）的语句，大概率缺索引或条件写法不佳
- 对高频慢SQL，结合 EXPLAIN 分析执行计划，优先考虑添加复合索引、避免 SELECT *
- 注意：数据量极小时 MySQL 可能主动放弃索引走全表扫描，这类也会被
log_queries_not_using_indexes记录，需结合实际数据量判断是否真有问题
