WHERE条件中对字段使用函数会导致索引失效，应将函数移至右侧或改用范围查询，如WHERE name = 'JOHN'或WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'。
WHERE 条件里用函数导致索引失效
只要 WHERE 子句对字段施加了函数调用，比如 WHERE UPPER(name) = 'JOHN' 或 WHERE DATE(created_at) = '2024-01-01'，绝大多数数据库（MySQL、PostgreSQL、SQL Server）都会跳过索引，走全表扫描。
真正有效的写法是把函数“挪到右边”，让左边保持原始列名：
-
WHERE name = UPPER('john')→ 改成WHERE name = 'JOHN'（大小写敏感时建函数索引或用COLLATE） -
WHERE DATE(created_at) = '2024-01-01'→ 改成WHERE created_at >= '2024-01-01' AND created_at - 如果必须用函数过滤（如模糊前缀不固定），考虑生成计算列+索引（MySQL 5.7+ / PostgreSQL 12+ 支持）
JOIN 顺序和驱动表选错引发性能雪崩
在 MySQL 中，EXPLAIN 显示的 id 和 table 执行顺序，不代表你写的 SQL 顺序；优化器会重排。但如果你用了 STRAIGHT_JOIN 或强制 USE INDEX，就可能锁死低效路径。
关键判断点：小结果集的表应该当驱动表（即先查出来，再拿它的值去匹配大表）。常见反模式：
- 用大用户表
LEFT JOIN小配置表，但没给配置表加索引 → 驱动表变大，嵌套循环爆炸 - 多表 JOIN 时，把带
LIMIT的子查询写在 FROM 里，却没加FORCE INDEX→ 优化器误判基数 - PostgreSQL 中
JOIN默认基于统计信息选顺序，但 ANALYZE 滞后会导致计划错误，定期跑ANALYZE table_name很必要
分页深翻（OFFSET 大值）拖垮响应时间
SELECT * FROM orders ORDER BY id DESC LIMIT 100 OFFSET 100000 这类语句，在 MySQL 中实际要扫描 100100 行再丢弃前 100000 行；PostgreSQL 同样严重，尤其涉及排序字段无索引或索引区分度低时。
真实生产环境应避免 OFFSET，改用游标分页（cursor-based pagination）：
- 上一页最后一条记录的
id（或组合键如(created_at, id)）作为下一页起点 - 查询写成
WHERE id ，索引可完全覆盖 - 注意：不能用
OFFSET+ORDER BY RAND()—— 全表随机排序成本极高，改用应用层抽样或预生成 ID 列表
隐式类型转换悄悄干掉索引
当 WHERE 左右两边数据类型不一致，比如字段是 VARCHAR，但条件写了 WHERE user_id = 123（数字字面量），MySQL 会把整列转成数字比对，触发全索引扫描甚至全表扫。
这种问题在日志类表或老系统中高频出现，因为字段定义混乱（user_id 是字符串，但业务代码传 int）：
- 用
EXPLAIN FORMAT=JSON查看key是否为null，并检查type是否是ALL或index - 显式转类型：把
WHERE user_id = 123改成WHERE user_id = '123'（前提是字段确实是字符串） - 更彻底的解法：统一字段类型，加 CHECK 约束防插入非法值，配合应用层校验
最麻烦的不是写错 SQL，而是线上跑了半年才发现某张千万级表的主键 JOIN 总是慢——只因一列被开发早期定义成了 TEXT，而另一端用 INT 去连。这种隐式转换不会报错，只会默默吃掉性能。
