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 刷盘，影响主从同步延迟。
- 拆分批量更新：把
UPDATE t SET status=1 WHERE id IN (1..10000)改为每 500 行一个事务 - 避免在事务里做 HTTP 调用、文件读写等外部耗时操作
- 用
SHOW ENGINE INNODB STATUS\G查看当前锁冲突，重点关注TRANSACTIONS和LOCK WAIT部分 - 监控
information_schema.INNODB_TRX表，对TRX_ROWS_MODIFIED > 10000或TRX_DURATION > 60的事务告警
JOIN 多表时驱动表选择错误引发全表扫描
MySQL 的嵌套循环连接（NLJ）依赖驱动表（外层表）尽可能小。如果优化器误选了大表作驱动表，就会对小表反复全扫描，性能指数级下降。常见于没统计信息、字段类型不一致或隐式转换的 JOIN 条件中。
- 用
EXPLAIN观察rows列：驱动表的预估扫描行数应明显小于被驱动表 - 确保关联字段类型严格一致，比如
user.id是BIGINT，order.user_id也必须是BIGINT，否则触发隐式转换，索引失效 - 必要时用
STRAIGHT_JOIN强制指定驱动表顺序，例如SELECT STRAIGHT_JOIN ... FROM small_table s JOIN large_table l ON s.id = l.small_id - 对复杂多表 JOIN，优先考虑冗余关键字段（如把
user_name冗余进order表），减少 JOIN 次数
SELECT /*+ USE_INDEX(orders idx_user_status) */ u.name, o.total FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' AND u.created_at > '2024-01-01' ORDER BY o.created_at DESC LIMIT 20;
真正卡住的往往不是单条语句，而是多个看似合理的小决策叠加：字段没收敛、索引没覆盖、事务没切分、JOIN 没对齐。这些地方不报错，但会悄悄吃掉吞吐和响应时间。
