SELECT * 拖慢查询因需读取整行、解析所有列并传输，尤其含TEXT/BLOB时I/O和内存开销大，且阻碍覆盖索引使用；应显式指定字段或加白名单控制。
为什么 SELECT * 会拖慢查询执行流程
不是所有字段都需要，但 MySQL 仍要从磁盘或缓冲池读取整行、解析所有列、再网络传输——尤其当表有 TEXT 或 BLOB 字段时，I/O 和内存开销会陡增。更隐蔽的问题是：它让优化器难以利用覆盖索引。
- 用
EXPLAIN检查Extra列是否出现Using where; Using index（说明走了覆盖索引），一旦写成SELECT *，这个提示大概率消失 - 显式列出需要的字段，比如把
SELECT *改成SELECT id, name, status - 如果应用层依赖动态字段，至少在 DAO 层做字段白名单控制，避免前端传
fields=*直接拼 SQL
ORDER BY + LIMIT 在无合适索引时的执行瓶颈
MySQL 并不会因为加了 LIMIT 10 就只排序前 10 行；它先按 ORDER BY 对全结果集排序，再截断。若没有能支撑排序的索引，就会触发 Using filesort，严重时消耗大量临时磁盘空间和 CPU。
- 确认排序字段是否在索引最左前缀上，例如
ORDER BY created_at DESC，应建索引INDEX idx_created (created_at)；若还带WHERE user_id = ?，则更适合INDEX idx_user_created (user_id, created_at) - 避免在排序字段上用函数，如
ORDER BY DATE(created_at)会让索引失效 - 对分页深翻场景（如
LIMIT 10000, 20），优先考虑游标分页：WHERE created_at
大事务导致的锁等待与 binlog 写入延迟
一个执行 5 秒的 UPDATE 语句，在 RR 隔离级别下可能持有行锁、间隙锁甚至 Next-Key 锁长达整个事务周期。其他会话在等锁时表现为 Waiting for table metadata lock 或 Locked 状态；同时，大事务还会阻塞 binlog 刷盘，影响主从同步延迟。
