必须从慢查询日志入手定位真实耗时SQL——先确认MySQL慢查询日志是否启用（SHOW VARIABLES LIKE 'slow_query_log'），再设置阈值（long_query_time）、分析日志（mysqldumpslow/EXPLAIN）、优化索引（复合索引顺序：等值→范围→排序）并验证效果。

PHP框架项目运行变慢，页面响应时间超过2秒，数据库查询成为瓶颈时，必须从慢查询日志入手定位真实耗时SQL。

不看日志，只调代码，永远找不到根因。

确认MySQL是否启用慢查询日志

登录MySQL命令行后，执行：SHOW VARIABLES LIKE 'slow_query_log';。

返回ON表示已开启；若为OFF，需先启用。

执行SET GLOBAL slow_query_log = ON;可临时开启，但重启后失效。

如需永久生效，编辑my.cnf，在[mysqld]下添加：slow_query_log = 1和slow_query_log_file = /var/log/mysql/mysql-slow.log。

【路径权限必须由mysql用户可写，否则日志写入失败且无报错提示】

同时设置阈值：SET GLOBAL long_query_time = 0.5;，将超过500毫秒的查询记入日志。

生产环境建议设为1.0，避免日志爆炸。

定位PHP框架中触发慢查询的具体请求

打开慢查询日志文件，例如/var/log/mysql/mysql-slow.log，用tail -f实时观察新条目。

在浏览器或Postman中复现卡顿接口，比如访问/api/ordersstatus=processing。

随后立即查看日志末尾新增的SQL块。

每条记录以# Time:开头，后面通常跟着# User@Host:和# Query_time:。

# Query_time:显示的是真实执行耗时，不是PHP层计时，因此更可信。

注意：Lara vel、ThinkPHP等框架常通过ORM拼接SQL。

日志里看到的可能是带问号占位符的预处理语句，需结合# Host和# Id字段，回溯对应PHP进程的请求路径。

分析慢查询SQL并针对性优化

方法一：用mysqldumpslow快速聚合统计

执行mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log，按总耗时排序，提取前10条最重的SQL模板。

它会自动合并参数不同的同类查询，例如WHERE id = 1和WHERE id = 2会归为同一类。

方法二：手动提取单条慢SQL执行EXPLAIN

复制日志中完整SQL，注意替换 → 实际值，尤其是日期范围、LIKE模糊值。

然后粘贴到MySQL客户端执行EXPLAIN FORMAT=TRADITIONAL [SQL];。

分析时重点看以下几项：

• type：若为ALL，说明全表扫描。
• rows：若数值远超实际结果集，说明索引未生效。
• Extra：若出现Using filesort或Using temporary，意味着排序或分组被迫落盘。

方法三：在PHP框架中加SQL钩子验证优化效果

在 Lara vel 里，可以直接在AppServiceProvider@register中挂上DB::listen()监听，把执行时间超过 300ms 的 SQL 做打点记录。

如果用的是 ThinkPHP，则可以通过Db::listen()来捕获。

这样一来，优化做完之后，这条 SQL 到底还有没有继续出现在慢日志里，就能核实得很清楚。

修复索引缺失问题

第一步：识别WHERE、ORDER BY、GROUP BY字段组合

例如日志中频繁出现SELECT * FROM orders WHERE status = ? AND created_at > ORDER BY updated_at DESC。

则复合索引应覆盖(status, created_at, updated_at)。

第二步：生成添加索引语句

执行ALTER TABLE orders ADD INDEX idx_status_created_updated (status, created_at, updated_at);。

注意字段顺序：等值条件放前，范围条件居中，排序字段放最后。

第三步：验证索引是否被命中

再次用EXPLAIN执行原SQL，确认key列显示刚创建的索引名。

同时观察rows是否大幅下降，比如从12万降到380。

第四步：删除冗余单列索引

如果表里原本已经有INDEX(status)和INDEX(created_at)，而新的复合索引本身就把这两列覆盖进去了，那么这两个旧索引继续保留意义就不大了。

它们反而会额外拖累写入性能。

这种情况下，直接执行DROP INDEX idx_status ON orders;和DROP INDEX idx_created_at ON orders;即可。