WHERE条件未走索引主因是隐式转换和函数包裹；如user_id='123'（BIGINT字段）或DATE(created_at)='2024-01-01'均致全表扫描；应改用id=1、created_at>='2024-01-01' AND created_at<'2024-01-02'。
WHERE 条件没走索引：隐式转换和函数包裹最常背锅
超时和锁等待的第一大源头，不是数据量大，而是 MySQL 或 PostgreSQL 根本没用上索引——你写了索引，它却视而不见。WHERE user_id = '123'（user_id 是 BIGINT）会触发隐式类型转换，全表扫描随之而来；WHERE DATE(created_at) = '2024-01-01' 则让 created_at 上的索引彻底失效。
- 查执行计划必须用
EXPLAIN FORMAT=JSON（MySQL）或EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL），重点看key是否非空、rows是否远超预期 - 禁止字符串和数字混用：
id = '1'→ 改成id = 1 - 时间范围改写为闭区间：
created_at >= '2024-01-01' AND created_at ，别碰 <code>DATE()、YEAR()这类函数 - 大小写和空格也影响索引：若字段
COLLATION是utf8mb4_bin，'abc'≠'ABC'，'abc '≠'abc'
UPDATE/DELETE 没带 LIMIT 或主键条件：一跑就锁表
线上执行 UPDATE orders SET status = 'done' WHERE user_id = 123，看着简单，但如果 user_id 没索引，MySQL 就真锁全表；即使有索引，匹配几万行也会让锁持有时间拉长，后续事务排队等死。PostgreSQL 虽不“锁表”，但大范围更新会让 tuple 锁堆积，引发严重等待链。
- 所有线上
UPDATE/DELETE必须满足其一：含主键或唯一键条件，或显式加LIMIT N（建议 ≤ 500） - 批量操作优先用
IN (id1, id2, ...)，避免模糊条件如status != 'done'（无法走索引） - 别在循环里拼
IN列表——单次超过 1000 个值易触发解析瓶颈，拆成多批更稳
SELECT FOR UPDATE 写在非事务方法里：锁关不掉，连等 8 小时
Spring Boot 中，如果直接在非 @Transactional 方法里调用 JdbcTemplate.queryForObject("SELECT ... FOR UPDATE", ...)，MySQL 会开隐式事务，但不会自动提交——锁一直挂着，直到连接超时（默认 8 小时）或被 KILL。线上一并发，几十个连接全卡在那儿，雪崩就来了。
- 强制所有
FOR UPDATE必须包裹在显式事务中，且事务内只做必要 DB 操作，立刻commit - MyBatis 的
@Select注解里禁写FOR UPDATE，改用@Update+ 显式事务控制 - PostgreSQL 对应写法是
SELECT ... FOR UPDATE NOWAIT，必须加NOWAIT并捕获SQLState 55P03异常，否则会无限等待
SELECT * + 大字段 + ORDER BY：OOM 杀手组合拳
SELECT * FROM logs WHERE app = 'payment' ORDER BY created_at DESC LIMIT 20 看似无害，但若 logs.content 是 TEXT 字段，且匹配行数达数十万，MySQL 会把每行完整内容读进内存排序——innodb_buffer_pool_size 很快打满，磁盘 I/O 暴涨，连接池耗尽，最后 OOM Killer 直接杀进程。
- 永远避免
SELECT *，尤其在 JOIN 或含大字段的场景，只取真正需要的列 -
ORDER BY + LIMIT必须命中覆盖索引：索引需包含WHERE字段 +ORDER BY字段 +SELECT中的非主键字段（否则回表） - 深分页（如
LIMIT 10000, 20）即使有索引也慢，改用游标分页：WHERE id - 大字段单独建表或延迟加载，业务层按需
JOIN或二次查询
实际排查时，很多人盯着慢日志看 Rows_examined，却忽略 EXPLAIN 里的 type 是 ALL 还是 range；也有人修复了 SQL，却忘了统计信息过期会让优化器继续选错执行计划——ANALYZE TABLE 不是可选项，是上线后必跑动作。
