必须先启用mysql慢查询日志并确认生效（show variables like 'slow_query_log'值为on），再用db::listen()捕获带真实参数的sql写入独立日志，grep筛选高频语句后，用具体参数explain验证执行计划，最后按where等值条件+order by顺序创建联合索引，并消除n+1查询。
线上Laravel应用响应变慢，页面加载卡顿，MySQL慢查询日志里频繁出现耗时超1秒的SELECT语句，部分查询甚至触发了Rows_examined远超表总行数的告警，必须立刻定位并修复真实瓶颈，而非仅靠缓存掩盖问题。
启用MySQL慢查询日志并确认生效
登录服务器，编辑MySQL配置文件/etc/my.cnf，在[mysqld]区块下添加三行：
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
重启MySQL服务：sudo systemctl restart mysql。执行SHOW VARIABLES LIKE 'slow_query%';，确保slow_query_log值为ON，否则后续所有分析都无效。
这一步不可跳过——没有真实慢日志，你优化的只是自己脑补的SQL。
用DB::listen()捕获带参数的真实查询
在app/Providers/AppServiceProvider.php的boot()方法中注册监听器：
DB::listen(function ($query) {
$sql = vsprintf(str_replace('?', '%s', $query->sql), $query->bindings);
$log = sprintf("[%s] %s —— Time: %.3fs | Rows: %d\n", now()->toDateTimeString(), $sql, $query->time, $query->connection->getPdo()->getAttribute(PDO::ATTR_PREFETCH) ?: 0);
>File::append(storage_path('logs/queries.log'), $log);
});
【必须写入独立日志文件，不能混入laravel.log】——grep筛选高频SQL时，混杂的日志会浪费你至少20分钟时间。
访问疑似慢的页面，然后执行grep -c "WHERE.*status" storage/logs/queries.log快速统计该类条件出现频次。
从日志中提取具体SQL并EXPLAIN验证
第一步：用tail -n 50 storage/logs/queries.log | grep "posts"找出最近一次涉及posts表的完整SQL，例如：
SELECT * FROM `posts` WHERE `user_id` = 123 AND `status` = 'published' ORDER BY `created_at` DESC LIMIT 20
第二步：复制该SQL，粘贴进phpMyAdmin或MySQL CLI，**在前面手动加上EXPLAIN**：
EXPLAIN SELECT * FROM `posts` WHERE `user_id` = 123 AND `status` = 'published' ORDER BY `created_at` DESC LIMIT 20;
第三步：紧盯输出中的type字段——若为ALL或index，说明正在全表扫描；若key为空，即使建了索引也未被选用。
注意：绝不能对带问号的预处理语句直接EXPLAIN，MySQL无法基于占位符生成真实执行计划。
按查询模式创建精准索引
方法一：单字段高频等值查询（如WHERE status = ?）
运行php artisan make:migration add_index_to_posts_status，在up()中写：$table->index('status');
方法二：复合条件查询（如WHERE user_id = ? AND status = ? ORDER BY created_at DESC）
建联合索引：$table->index(['user_id', 'status', 'created_at']);
【顺序不可颠倒：等值条件(user_id、status)必须在前，排序字段(created_at)必须在最后】——若写成['created_at', 'user_id']，ORDER BY部分能走索引，但WHERE里user_id就失效了。
方法三：软删除表必加索引
有deleted_at字段的表，只要存在whereNull('deleted_at')，就必须建索引：$table->index(['deleted_at', 'id']);——覆盖索引可同时支撑过滤与分页排序。
消除N+1查询并验证效果
第一步：打开Laravel Telescope或在控制器中临时插入：
DB::enableQueryLog();
$users = User::with('posts', 'profile')->get();
dd(DB::getQueryLog());
第二步：检查输出数组长度——若之前是37条SQL（N+1），现在应稳定在3~5条（主表+各关联表1条）。
第三步：重点检查预加载的关联字段是否已建索引，例如posts.user_id必须有索引，否则with('posts')生成的IN (1,2,3...)查询本身就会变慢。
这一步操作起来很简单，直接把with()加到查询链上就行，但没索引支撑的预加载只是把慢从循环里挪到了一条大SQL里。
禁用持久连接避免连接泄漏
打开config/database.php，找到mysql配置块，在'options'数组中强制设置：
PDO::ATTR_PERSISTENT => false,
接着在任意路由中加入测试代码：
dd(DB::connection()->getPdo() === DB::connection()->getPdo());
返回true才表示PDO实例被正确复用。
如果返回false，说明连接未复用，每个查询都在新建连接——这在高并发下会迅速耗尽MySQL最大连接数。
