LEFT JOIN在视图中会导致右表索引失效，因优化器被迫全量扫描右表且无法反向裁剪；正确做法是将过滤条件写入ON子句、更新统计信息、避免函数操作，并确保连接字段类型一致。
LEFT JOIN在视图里会让优化器“不敢用”右表索引
视图里的LEFT JOIN不是“连完再筛”，而是强制先拉全量左表，再逐行匹配右表——哪怕你主查询只选左表三列，LEFT JOIN定义中的右表仍会被完整扫描。此时右表连接字段即使有索引，也常因基数估算失真（优化器以为右表要扫10000行）而放弃使用，转为全表扫描。
常见错误现象：EXPLAIN显示右表type是ALL，key为NULL，rows列数值远超实际匹配行数。
- MySQL不支持基于主查询
SELECT列反向裁剪视图中的LEFT JOIN，只要视图定义写了它，就必执行 - 视图没写
WHERE过滤右表，等价于WHERE 1=1，优化器无法估计右表有效数据量，索引选择率判断失效 - 嵌套视图会叠加这种效应：每层
LEFT JOIN都让右表索引利用率进一步下降
WHERE条件放错位置，索引直接失效
在视图外的主查询里对右表字段加WHERE（比如WHERE order_status = 'shipped'），不会提前缩小右表参与关联的数据集——它是在LEFT JOIN生成含大量NULL的中间结果后才执行的过滤。此时右表早已被全量扫描过一遍，索引毫无作用。
真正有效的做法是把业务过滤条件写进视图定义的ON子句里：
LEFT JOIN orders o ON u.id = o.user_id AND o.status IN ('shipped', 'delivered')
-
ON里的条件能参与连接过程，让优化器有机会用上status和user_id的联合索引 - 若必须用
WHERE，只用于左表字段（如WHERE u.is_active = 1），否则语义已退化为INNER JOIN - 右表字段在
WHERE中出现IS NOT NULL，同样触发隐式转换，应改用ON条件
右表字段索引建了也不管用？检查统计信息是否过期
即使右表连接字段建了索引，如果ANALYZE TABLE长期没跑，优化器拿到的行数统计仍是旧的（比如显示右表只有100行，实际已涨到100万）。它会误判LEFT JOIN代价低，选择嵌套循环（NLJ），导致每条左表记录都触发一次右表索引查找——高并发下Handler_read_rnd_next飙升。
- 执行
ANALYZE TABLE orders更新统计信息，尤其在右表数据批量导入后 - MySQL 8.0+可开启
innodb_stats_auto_recalc = ON，但大表慎用，避免分析阻塞写入 - 对宽表（列多、TEXT/BLOB字段多），统计信息误差更明显，建议定期手动
ANALYZE
视图里LEFT JOIN + 函数ON条件，索引百分百失效
比如视图定义中写LEFT JOIN logs l ON u.id = CAST(l.user_id AS SIGNED)，或ON UPPER(u.email) = UPPER(l.email)，右表user_id或email上的索引完全无法命中。优化器只能对右表每行计算函数再比对，数据量一过万就卡死。
- 连接字段两侧必须保持原始类型与形态一致：整型对整型，字符串对字符串，大小写敏感则统一存小写
- 实在需要函数匹配，MySQL 8.0+可用函数索引：
CREATE INDEX idx_log_email_upper ON logs ((UPPER(email))) - Oracle/PostgreSQL支持表达式索引，但MySQL 5.7及更早版本不支持，只能重构数据存储格式
LEFT JOIN一旦写进视图，就等于给主查询埋了个固定执行路径——索引能否生效，取决于这个路径里每一步是否满足最严苛的使用条件。 
