视图嵌套导致JOIN字段类型或排序规则不一致，使优化器无法使用索引，表现为EXPLAIN显示type: ALL、key: NULL；根本原因是嵌套后SQL展开时类型强制转换、谓词无法下推、统计信息失真及LEFT JOIN条件错放。
视图嵌套后JOIN字段类型/排序规则不一致
视图本身不存数据，执行时会被数据库“展开”成原始SQL。一旦嵌套两层以上，比如 v_user_orders 套在 v_active_users 里，最终生成的语句可能把 users.id（INT）和 orders.user_id（VARCHAR）硬凑在一起做等值比较——B+树索引无法跨类型匹配，优化器直接放弃走索引，EXPLAIN 显示 type: ALL、key: NULL。
常见诱因包括：
- 底层表字段定义不统一：用
SHOW FULL COLUMNS FROM users LIKE 'id'和SHOW FULL COLUMNS FROM orders LIKE 'user_id'对比，看Type和Collation是否完全一致 - ETL脚本或导入工具默认把数字ID建为字符串，而业务代码当整型用
- 视图A里用了
UPPER(email)，视图B又拿这个结果去JOIN另一张表的email字段，导致隐式转换
嵌套视图抑制谓词下推
外层查询加的 WHERE 条件，比如 WHERE o.status = 'shipped'，在嵌套视图中大概率无法下推到基表扫描节点。执行计划里你会看到 Filter 出现在最外层，而基表行数预估爆炸（rows: 1000000），Access Predicates 为空。
根本原因是数据库把嵌套视图当作“黑盒”，不再重分析中间结果集大小。尤其当某层视图含 GROUP BY、DISTINCT 或窗口函数时，优化器彻底放弃下推。
可验证方式：
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）看是否只有leaf节点显示视图名，看不到真实表名 - 手动展开视图定义，把嵌套部分替换成子查询再跑
EXPLAIN，对比执行计划差异 - 若展开后索引立刻生效，基本锁定是嵌套结构导致的下推失败
嵌套LEFT JOIN叠加索引失效效应
每层视图里的 LEFT JOIN 都会让右表索引利用率进一步下降。第一层 LEFT JOIN orders 已让 orders 表扫描不可控；第二层再 LEFT JOIN logs，优化器面对的是“orders + logs”的逻辑组合，根本没法单独评估 logs.user_id 索引的有效性。
更麻烦的是，嵌套后 ON 条件容易被写错位置：
- 错误写法：
WHERE logs.level = 'ERROR'（在最外层）→ 先全量拉出带NULL的日志行，再过滤 - 正确写法：
LEFT JOIN logs ON u.id = logs.user_id AND logs.level = 'ERROR'（条件必须进ON）→ 让优化器有机会用上(user_id, level)联合索引 - 如果嵌套太深，开发者常漏掉这一层，以为“反正我在外面WHERE了”，实际已晚
统计信息过期 + 多层估算失真
嵌套视图会放大基数估算误差。假设第一层视图预估返回100行，第二层再JOIN一张表，优化器就按100 × 右表总行数估算代价；但实际第一层可能返回5万行——这会导致它选错驱动表、误判哈希连接内存够不够、甚至触发 Spill to TempDB（SQL Server）或磁盘临时表（MySQL）。
解决动作要具体：
- 对每张底表单独执行
ANALYZE TABLE orders、ANALYZE TABLE logs，别只分析视图 - 避免依赖
innodb_stats_auto_recalc = ON，大表自动分析可能阻塞写入 - 检查
SELECT COUNT(*) FROM orders WHERE user_id IS NULL，NULL比例超10%时，user_id索引选择性已严重退化
