sql中不建议在join的on条件中使用函数运算，因为函数会破坏索引有效性，导致优化器无法映射到b+树索引，被迫全表扫描或使用join buffer；应通过业务层标准化存储、生成列加索引或前置处理规避。
因为函数会破坏索引有效性，导致数据库放弃使用索引，转而执行全表扫描或 join buffer 匹配。
ON 子句里用 UPPER()、DATE() 等函数直接让索引失效
只要 JOIN 字段被任意函数包裹（如 UPPER(a.name) = UPPER(b.name) 或 DATE(a.created_at) = DATE(b.date)），优化器就无法将该字段与索引 B+ 树的有序结构对齐——它不知道函数输出值是否仍保持单调性，也不敢下推过滤条件。
- MySQL/PostgreSQL 都不支持对函数表达式直接建立普通索引（除非显式建函数索引）
- 即使两边字段类型、字符集、索引都一模一样，
ON UPPER(a.name) = UPPER(b.name)也会让执行计划中被驱动表的type变成ALL，key为空 - PostgreSQL 还可能因隐式转换把整张大表 cast 成 text 再比对，500 万行订单表耗时从 80ms 涨到 6.2s
字符集或 COLLATION 不一致时，函数“补救”写法反而更慢
有人发现 JOIN 慢，就想着在 ON 里硬加 COLLATE 强制统一，比如 t1.name COLLATE utf8mb4_0900_as_cs = t2.name COLLATE utf8mb4_0900_as_cs。这看似绕过了报错，但实际几乎不解决问题。
- MySQL 优化器会在生成执行计划前做语义推导，只要字段原始
COLLATION不同，就大概率拒绝走索引 - 这种写法无法命中已有索引，等效于在每行上实时计算 collation 转换，CPU 开销翻倍
- 正确做法是用
ALTER TABLE ... MODIFY统一字段定义，且必须同时指定CHARACTER SET和COLLATE
想用函数又想快？只有两种靠谱路径
真有业务必须做大小写不敏感或日期截断匹配，不能靠 ON 里硬套函数临时应付。
- 建函数索引（MySQL 8.0+/PostgreSQL）：
CREATE INDEX idx_users_name_lower ON users ((LOWER(name)))，然后 ON 里写LOWER(a.name) = LOWER(b.name) - 提前标准化存储：用户注册时就把
name存为小写，JOIN 直接用原始字段比对，零运行时开销 - 避免在 JOIN 中处理时间精度：不要用
DATE(order_time) = '2026-07-20'，改用order_time >= '2026-07-20' AND order_time ，才能走 <code>order_time上的索引
真正卡住性能的，往往不是函数本身多慢，而是它让数据库彻底放弃索引路径，退化成暴力匹配。检查 EXPLAIN 里被驱动表的 type 和 key，比看 SQL 写得“多优雅”管用得多。
