WHERE条件未走索引主因是隐式转换和函数包裹；如user_id=’123’（BIGINT字段）或DATE(created_at)=’2024-01-01’均致全表扫描；应改用id=1、created_at>=’2024-01-01′ AND created_at
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 ，别碰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。线上一并发，几十个连接全卡在那儿，雪崩就来了。
