JOIN条件中避免对字段套函数或使用复杂表达式，否则索引失效；应统一字段类型与大小写处理方式，优化连接顺序并前置过滤条件，每次改写后需用EXPLAIN ANALYZE验证执行计划。
JOIN条件里别对字段套函数
数据库没法用索引加速 ON UPPER(a.name) = UPPER(b.name) 这种写法，哪怕两边都有索引，也会退化成全表扫描。本质是函数改变了字段原始值，优化器无法匹配索引定义。
- 改成
ON a.name = b.name，确保大小写一致靠数据清洗或统一 COLLATION - 真要忽略大小写，用
COLLATE utf8mb4_0900_as_cs（MySQL 8.0+）或COLLATE SQL_Latin1_General_CP1_CI_AS（SQL Server），而不是函数包裹 - PostgreSQL 可建函数索引：
CREATE INDEX idx_name_lower ON users ((lower(name)))，但只对固定函数有效，不能覆盖任意表达式
JOIN谓词里避免复杂表达式
ON a.created_at + INTERVAL '1 day' = b.event_time 看似合理，实则让优化器放弃索引选择。表达式导致字段值被“计算后比较”，等价于对每行都做一次运算。
- 优先把计算挪到常量侧：比如改写为
ON a.created_at = b.event_time - INTERVAL '1 day'，部分引擎（如 PostgreSQL、Oracle）能识别并下推索引扫描 - MySQL 5.7+ 对
DATE_SUB(b.event_time, INTERVAL 1 DAY)这类也支持索引下推，但需确保右侧无列参与运算 - 实在绕不开，考虑冗余字段：在
a表加created_at_next_day并建索引，用空间换查询效率
多表JOIN时注意连接顺序与驱动表
不是所有 JOIN 都能自动选最优顺序。尤其当某张表过滤条件弱（比如只有 status = 'pending' 且该值占比 80%），它若被当作驱动表，就会放大后续 JOIN 的中间结果集。
- 用
EXPLAIN看rows和filtered列：数值越大越危险 - MySQL 可用
STRAIGHT_JOIN强制顺序，但得先确认小结果集表是哪个；PostgreSQL 用SET enable_hashjoin = off临时测试嵌套循环效果 - WHERE 条件尽量前置到对应表的 JOIN 条件里，比如
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'，比放在末尾 WHERE 更早裁剪
NULL 值和类型隐式转换悄悄拖慢 JOIN
ON a.user_id = b.uid 如果一边是 INT、另一边是 VARCHAR，MySQL 会把整列转成字符串再比对——全表函数计算，还可能因字符集不同触发额外转换。
- 用
SHOW CREATE TABLE检查字段类型是否完全一致，包括符号性（SIGNED/UNSIGNED）、字符集、排序规则 -
IS NULL在 JOIN 条件中基本无法走索引，如果业务允许，用默认值（如0或'unknown'）替代 NULL，并在应用层区分语义 - PostgreSQL 对 NULL 处理更透明，但
COALESCE(a.id, 0) = COALESCE(b.id, 0)同样破坏索引，别这么写
最麻烦的从来不是语法对不对，而是你以为的“等价改写”其实在执行计划里彻底变了味。每次调换表达式位置、加个函数、改个类型，最好都跑一遍 EXPLAIN ANALYZE 看真实行为。
