高并发下应聚焦高频重复SQL和索引未命中，而非单条慢查询；DB::listen()须在AppServiceProvider::boot()全局注册，拼接SQL与bindings后写入独立日志文件，按SQL模板频次排序分析，结合EXPLAIN重点观察key、rows、Extra三列，并确保联合索引顺序匹配最左前缀，大表加索引必须用ALGORITHM=INPLACE。
高并发下慢查询日志本身不解决性能问题，只暴露表象；真正要抓的是「高频重复 SQL」和「索引未命中」，而不是单条耗时超过 1s 的语句。
DB::listen() 必须在 AppServiceProvider::boot() 中注册
中间件、Artisan 命令、队列任务都依赖这个全局监听器，漏掉任一环节就会丢失关键上下文。只在控制器里临时加 DB::listen() 是无效的。
- 监听函数必须拼接
$query->sql和$query->bindings，用vsprintf()替换问号，否则无法在 phpMyAdmin 或 MySQL CLI 中复现执行计划 - 日志写入独立文件（如
storage/logs/queries.log），避免混进laravel.log，否则grep效率极低 - 别设固定阈值（如
time > 1000），高并发下 N+1 查询单次可能仅 12ms，但 500 次叠加就是 6 秒 —— 要按 SQL 模板频次排序，不是按耗时排序
MySQL slow_query_log 是生产环境唯一可信入口
云数据库（如阿里云 RDS）需在控制台开启“SQL 审计日志”，而非执行 SET GLOBAL；自建 MySQL 则必须确认有 SUPER 权限，且 long_query_time = 0.5（单位是秒）比设为 1 更容易捕获 N+1 累积延迟。
-
log_output = 'TABLE'写入mysql.slow_log表，方便用 Laravel 直接查：DB::table('mysql.slow_log')->orderByDesc('start_time')->limit(10)->get() - 日志里看到连续多行
SELECT * FROM users WHERE id = ?，时间戳间隔 Rows_examined = 1，就是典型 N+1，不是慢查询本身的问题 - 别信
Query_time数值：它不含网络往返、连接建立、结果集序列化开销，真实用户感知延迟远高于该值
EXPLAIN 必须传真实参数，不能直接跑带问号的 SQL
从日志里复制 SELECT * FROM orders WHERE status = ? AND paid_at > ? 到 phpMyAdmin 执行 EXPLAIN，结果一定是 type=ALL —— 因为 MySQL 无法基于问号估算执行计划。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 正确做法：从日志中挑出一次具体调用，例如
status = 'paid' AND paid_at > '2026-04-20'，拼成完整 SQL 再EXPLAIN SELECT - 重点看三列：
key是否非 NULL、rows是否远小于表总行数、Extra是否含Using filesort或Using temporary - 联合索引顺序必须匹配 WHERE 条件最左前缀：
INDEX(status, paid_at)有效，INDEX(paid_at, status)对该查询完全无效
大表加索引必须用 ALGORITHM=INPLACE
Laravel 迁移默认的 Schema::table(...)->index(...) 在百万级表上会锁表几分钟，导致高并发请求大面积超时。
- 线上加索引务必用原生语句：
DB::statement("ALTER TABLE orders ADD INDEX idx_status_paid (status, paid_at) ALGORITHM=INPLACE") - 软删除字段
deleted_at参与查询（如where deleted_at is null）时，B-tree 索引对IS NULL不生效，必须单独建索引或包含在联合索引最右位 - 外键字段（如
user_id）不自动建索引，whereHas()、withCount()等隐式关联操作极易触发全表扫描，必须手动补
高频 SQL 的参数分布比执行计划更关键：同一语句出现 37 次，其中 35 次参数落在冷数据区间（如 created_at ），而索引只覆盖热数据，这种“局部失效”最难排查，也最容易被忽略。
