必须从慢查询日志入手定位真实耗时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/orders?status=processing，立即查看日志末尾新增的SQL块。
每条记录以# Time:开头，紧随其后是# User@Host:和# Query_time:——这个时间就是真实执行耗时，不是PHP层计时，更可信。
注意：Laravel、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钩子验证优化效果
Laravel可在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;。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
