JOIN中使用RAND()、UUID()等非确定性函数必然导致索引失效，因优化器无法预计算其结果，无法映射到B+树索引；MySQL函数索引要求函数必须DETERMINISTIC，故此类函数不可建索引；替代方案是将动态逻辑移至应用层或使用生成列。
JOIN条件里用RAND()、UUID()这类函数，索引必然失效
非确定性函数（如 RAND()、UUID()、NOW()、SYSDATE()）每次调用返回值都不同，数据库优化器无法预计算其结果，也就无法将它映射到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不支持对非确定性函数建函数索引
MySQL 8.0+ 虽支持函数索引，但明确要求函数必须是「确定性」的（DETERMINISTIC），即相同输入永远返回相同输出。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层移走，否则性能断崖不可避免。
- 需要随机关联？先在应用层生成一批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，要么接受全表扫描。
