Laravel数据库查询优化_Laravel查询优化详解【详解】-Laravel-PHP中文网

Laravel查询慢八成因SQL未走索引，应先用DB::select('EXPLAIN...')分析执行计划，type为ALL即全表扫描；WHERE字段无索引需立即添加，复合查询建联合索引时等值条件在前、范围条件在后；with()预加载仅适用于主表少、关联有索引、层级≤2场景，深层嵌套宜用join或hasManyThrough；chunkById()比chunk()更稳但不可用于事务，UUID主键需按created_at分段并加索引；soft delete字段deleted_at未索引会导致全表扫描，建议建(deleted_at, id)覆盖索引。

laravel数据库查询优化_laravel查询优化详解【详解】

查得慢，先看 `EXPLAIN` 而不是改代码

Laravel 查询慢，八成不是 Eloquent 写得丑，而是底层 SQL 没走索引。别急着加 ->with() 或拆查询，先让数据库自己说清楚它在干嘛。

在 Tinker 或临时路由里执行：

DB::select('EXPLAIN SELECT * FROM users WHERE email = ?', ['test@example.com']);

观察 type 字段：要是 ALL，说明全表扫描；ref 或 range 才算健康。注意 Laravel 的 ->toSql() 不带绑定值，直接拼进去看执行计划容易误判——务必用 DB::select('EXPLAIN ...', [...]) 这种带参数绑定的方式。

WHERE 条件字段没建索引？立刻加：php artisan make:migration add_index_to_users_email → $table->index('email')
复合查询（比如 WHERE status = ? AND created_at > ?）要建联合索引，顺序不能错：等值条件在前，范围条件在后
MySQL 8.0+ 支持隐藏索引，测试时可用 ALTER TABLE users ALTER COLUMN email SET INVISIBLE 临时关掉某个索引看影响

`with()` 预加载不是万能的，嵌套深了反而更慢

写 ->with(['posts.comments.author']) 看起来很优雅，但 Laravel 默认用 N+1 式的多条 SELECT 拼合数据，中间层一多，连接数、内存、序列化开销全上来。

真正要压平关联，得靠 ->join() + 手动映射，或者换 hasManyThrough 这类原生关系。Eager loading 只适合「主表少、关联表有索引、层级 ≤2」的场景。

检查生成的 SQL：如果 with() 后出现多个 SELECT ... FROM comments WHERE post_id IN (1,2,3,...)，且 post_id 没索引，就等于把压力从数据库转移到 PHP 进程
->withCount() 比 ->with() 更轻量，只要总数不要详情时优先选它
想查「用户+最新一条帖子」？别用 ->with(['posts' => fn($q) => $q->latest()->limit(1)])，这会为每个用户都跑一次子查询——改用 JOIN + 窗口函数或分组 MAX(id)

`chunkById()` 比 `chunk()` 更稳，但别在事务里用

处理几万行数据时，->chunk(1000) 看似安全，实际依赖 id BETWEEN ? AND ?，一旦中间删过记录，就会漏数据或重复处理。而 chunkById() 基于主键偏移，跳过已处理 ID，可靠性高得多。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

但它有个硬限制：必须用自增整型主键，且不能在数据库事务中调用——因为每次 chunk 是独立查询，事务里锁表会导致后续 chunk 等待超时。

替代方案：用 cursorPaginate()（Laravel 8.76+），基于游标，无状态，适合队列任务
如果主键是 UUID，chunkById() 无效，得手动按 created_at 分段，且确保该字段有索引+不重复
chunk 过程中更新同表数据？小心 MySQL 的 REPEATABLE READ 隔离级别导致幻读——加 SELECT ... FOR UPDATE 锁住范围，或改用 WHERE id > ? ORDER BY id LIMIT ? 手动翻页

软删除字段没索引，`deleted_at IS NULL` 就是性能黑洞

Laravel 默认给所有带 SoftDeletes 的模型自动加 WHERE deleted_at IS NULL，但如果 deleted_at 没索引，这个条件会让原本能走索引的查询直接退化为全表扫描。

尤其在高频查询的列表页（如后台订单页），加上软删除后响应时间翻倍，往往就是这个原因。

补索引很简单：$table->index('deleted_at')，但要注意：单列索引对 IS NULL 效果有限，MySQL 5.7+ 推荐建 INDEX(deleted_at, id) 这类覆盖索引
如果 99% 数据都是未删除的，索引收益低，可考虑关闭软删除，改用状态字段 + 应用层过滤
运行 php artisan tinker 时用 User::withTrashed()->where('deleted_at', '!=', null)->count() 查下真实删除比例，再决定要不要索引

索引不是越多越好，但 deleted_at 这种全局过滤字段，漏掉它基本等于给所有查询埋雷。