必须立即改写SELECT *为显式字段查询并规避N+1、全表扫描等隐患：开启SQL日志，定位rows_examined远大于返回行数的慢SQL；补全业务所需字段，关联查询也需限制字段；确保WHERE条件类型一致、日期用whereBetween、模糊查询避免前导通配符；大字段须单独处理且禁用排序分组。
Hyperf 3.1项目中遇到慢查询，日志显示SELECT *耗时突增且内存占用飙升，必须立即改写为显式字段查询并规避N+1、全表扫描等隐患。
查出具体哪条SQL在拖慢响应
打开 config/autoload/db.php，确认已开启 SQL 日志记录：【'enable_query_log' => true】。启动服务后复现请求，直接翻 runtime/logs/sql.log，找执行时间 >500ms 的 SELECT 语句——别信业务层日志，它可能被协程调度掩盖真实耗时。
重点看 【rows_examined】 字段：若该值远大于返回行数（比如查10行却扫描了10万行），说明没走索引或用了函数导致索引失效。
把 SELECT * 替换为明确字段列表
第一步：在对应模型的查询构造器中，删掉 ->select('*') 或 ->get() 前未指定字段的调用。
第二步：逐个补全业务真正需要的字段，例如：->select('id', 'name', 'status', 'created_at')。注意：如果后续要调用 $user->avatar_url，这个字段也得提前加进去，否则 Eloquent 会触发延迟加载——这就是 N+1 的起点。
第三步：检查是否用了 with() 预加载。如果预加载关联模型（如 User::with('posts')）但只展示用户头像和昵称，【posts 表的全部字段仍会被查出来】，必须给关联查询也加字段限制：->with(['posts' => function ($q) { $q->select('id', 'title', 'user_id'); }])。
避免隐式类型转换导致索引失效
方法一：WHERE 条件中字段类型与传入参数严格一致。比如数据库 user.id 是 BIGINT，就绝不能传字符串 where('id', '123')——PHP 会自动转成 int，但 MySQL 可能不走索引。改成 where('id', (int) $id) 或直接用绑定参数 where('id', $id)（Eloquent 自动处理类型）。
方法二：日期范围查询别用 whereDate()，它会把 created_at 字段套上 DATE() 函数，导致索引失效。改用 whereBetween('created_at', [$start, $end])，$start 和 $end 必须是 Y-m-d H:i:s 格式字符串。
方法三：模糊查询慎用 like '%关键词%'。前导通配符会让索引完全失效。如果必须全文搜索，【改用 MySQL 全文索引或 Elasticsearch】，不要硬扛。
大字段（TEXT/BLOB）必须单独处理
① 在主查询中主动排除大字段：比如用户表有 resume_content TEXT 字段，日常列表页绝对不要查它。建一个视图或专用 DTO 查询类，只在简历详情页才查该字段。
② 若必须连表查出大字段，用 Cursor 游标逐行读取：先关缓冲 $pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false)，再用 while ($row = $stmt->fetch()) 处理，每行处理完立刻 unset($row['resume_content'])，防止内存累积。
③ 禁止对大字段做 ORDER BY 或 GROUP BY —— 这会强制使用磁盘临时表，速度断崖下跌。
