线上 Laravel 变慢应先排查真实瓶颈而非盲目改代码，重点检查高频重复查询、索引失效、N+1问题、冗余中间件及服务器/数据库资源状态。
线上 Laravel 突然变慢，别急着改代码，先聚焦真实瓶颈。多数情况不是“某条 SQL 特别慢”，而是高频重复查询、索引失效或资源争用导致整体响应拖累。排查要快、准、有层次。
查数据库查询频次和模式
慢的根源常藏在“不慢但反复执行”的 SQL 里。比如循环中查用户头像、列表页反复查状态计数——单次 20ms，100 次就是 2 秒。
- 立刻启用
DB::listen()（必须在AppServiceProvider::boot()中注册），写入独立日志文件（如storage/logs/queries.log） - 用
grep -c "SELECT.*FROM users WHERE id = ?" storage/logs/queries.log统计高频语句出现次数，比看“耗时 >1000ms”更有效 - 挑出高频语句，把日志里的
bindings带入，拼成完整 SQL（如vsprintf($sql, $bindings)），再进 phpMyAdmin 或命令行执行EXPLAIN
查索引是否还在生效
数据量涨了、查询条件变了、联合索引顺序不对，都可能让索引“形同虚设”。EXPLAIN 显示 type=ALL 或 rows 远超表总行数，就是明确信号。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 重点检查：WHERE 条件字段有没有索引？外键、软删除字段（
deleted_at）是否手动加了索引？ - 联合索引必须严格匹配 WHERE 条件顺序，
INDEX(status, created_at)对WHERE status = ? AND created_at > ?有效，反过来就无效 - 带
ORDER BY ... LIMIT的分页查询，排序字段没索引或不在联合索引最右，Extra会显示Using filesort
查是否有 N+1 查询或冗余中间件
这是线上突然变慢最常见、最容易被忽略的两个“隐形杀手”。
- 打开 Debugbar 或 Telescope，看单个请求发了多少条 SQL；如果列表页加载伴随几十上百条相似
SELECT * FROM users WHERE id = ?，基本就是 N+1 - 检查路由是否误用了
web中间件组（含 session、CSRF、view 等），API 路由应只挂api中间件 - 确认关键接口是否启用了不必要的全局中间件，比如权限校验逻辑复杂却对所有请求都执行
查服务器与数据库资源状态
代码没动，但服务器负载或数据库配置变了，也会引发性能滑坡。
- 快速看 CPU、内存、磁盘 I/O：CPU 持续 >90%、内存频繁 swap、I/O 等待 >50ms，说明硬件或配置已成瓶颈
- 登录数据库执行
SHOW ENGINE INNODB STATUS，关注TRANSACTIONS部分是否有长时间未提交事务阻塞其他查询 - 检查 MySQL 统计信息是否过期：
ANALYZE TABLE your_table，尤其在 AWS RDS 等托管环境中，统计信息滞后很常见
