非确定性函数在SQL Join条件中为何导致全表扫描？

在JOIN条件中使用非确定性函数时，有一个结论必须明确：只要JOIN条件里出现RAND()、UUID()这类函数，索引就必然失效，没有例外。

原因在于非确定性函数每次调用返回值都不同，数据库优化器无法预计算结果，自然也无法将其映射到B+树索引的有序结构上。即使关联字段本身有索引，只要一侧被这类函数包裹，该侧索引就会立刻失效。

以下是典型示例：

• ON u.id = FLOOR(RAND() * 100)：此时u.id的索引完全无法使用，优化器只能进行全表扫描并逐行比对。
• LEFT JOIN log l ON l.trace_id = CONCAT('tr-', UUID())：l.trace_id的索引同样失效，右表失去任何过滤能力。
• 即使写成ON t1.code = t2.code AND t2.created_at > NOW() - INTERVAL 1 DAY，NOW()虽不影响等值字段，但若将其挪到等值位置，例如ON t1.ts = UNIX_TIMESTAMP(NOW())，同样会触发全表扫描。

可能会有人问：MySQL不是支持函数索引吗？能否针对RAND()或UUID()建立函数索引来补救？答案是否定的。MySQL 8.0+虽然提供了函数索引功能，但要求函数必须是“确定性”的——相同输入必须永远返回相同输出。RAND()和UUID()天生违反这一前提，DDL执行时会直接报错：ERROR 3950 (HY000): Expression #1 of index 'idx_rand' is not deterministic。既然无法建立索引，自然也无法借助它进行优化。

• CREATE INDEX idx_uuid ON events (UUID()) → 语法拒绝
• CREATE INDEX idx_now ON logs (DATE(NOW())) 同样失败，因为NOW()不是确定性函数
• 连SYSDATE()也不行——它与NOW()行为相似，但更强调“执行时刻”，同样属于非确定性函数

替代方案：将动态逻辑移出SQL层

既然此路不通，那么如何实现类似效果？例如随机抽样关联或按当前时间范围过滤，必须将计算从SQL层移走，否则性能将急剧下降。

推荐以下可行做法：

• 需要随机关联？先在应用层生成一批ID，例如使用SELECT id FROM users ORDER BY RAND() LIMIT 100，然后用这100个ID进行IN查询或临时表JOIN。
• 想按“最近1小时”关联日志？使用WHERE l.event_time >= NOW() - INTERVAL 1 HOUR单独过滤右表，再与左表进行等值JOIN，确保event_time字段有索引可用。
• 真正需要将UUID作为关联键？可以采用STORED GENERATED COLUMN加普通索引的组合：ALTER TABLE orders ADD uuid_lower CHAR(36) AS (LOWER(uuid)) STORED, ADD INDEX idx_uuid_lower (uuid_lower)。

LEFT JOIN遇到非确定性函数更加危险

INNER JOIN至少可以依靠驱动表过滤来缩小右表的扫描量，但LEFT JOIN则不同。一旦右表的JOIN条件中包含非确定性函数，优化器通常会放弃哈希连接，退回到嵌套循环，并对右表每行都重复执行一次函数——相当于对右表进行了N次全表扫描（N等于左表行数）。

• EXPLAIN中如果看到右表显示type=ALL，且rows稳定等于右表总行数，基本就是这个原因。
• Extra列出现Using join buffer (Block Nested Loop)加上Not exists的组合，大概率是函数导致右表索引不可用。
• 最坏情况下，即使左表只有10行，右表有10万行，最终也可能需要扫描100万行——10乘以10万，这个数字不可忽视。

结论很明确：非确定性函数在JOIN中不仅“可能慢”，而是“必然破坏索引路径”。与大小写转换等问题不同，它们可以依靠生成列兜底，但这里没有妥协余地——要么将函数移出SQL，要么接受全表扫描。