mysql优化器对视图采用黑盒处理，不重排表顺序、不下推条件、不合并视图（5.7及更早完全不支持，8.0+遇子查询等仍退化），导致执行计划失真、索引失效、锁序混乱及嵌套失控。
MySQL优化器对视图不做重优化，只当黑盒处理
视图在MySQL里不是“展开后再优化”，而是先解析成一个固定逻辑单元，再套上外层条件。一旦视图定义里有FROM t1 JOIN t2 JOIN t3 JOIN t4，优化器就不再尝试重排这四张表的顺序，也不重新估算中间结果集大小——它看到的不是四张表，而是一个叫v_orders_full的“黑盒”。
典型表现是EXPLAIN里rows字段严重偏低（比如预估87行，实际扫描32万行），驱动表选错，type变成ALL或index，索引形同虚设。
- MySQL 5.7及更早版本完全不支持视图合并（view merging），哪怕你只查
v_orders_full.id，也会先执行完整JOIN再过滤 - MySQL 8.0+虽支持部分合并，但遇到子查询、
GROUP BY、ORDER BY或函数包裹字段时，仍会退化为黑盒处理 -
EXPLAIN FORMAT=TREE里如果只看到leaf节点是视图名，没出现真实表名，说明优化器已放弃展开
条件下推失败，WHERE条件卡在最外层
你在调用视图时加了WHERE status = 'shipped' AND created_at > '2026-09-01'，但视图定义里已经写了WHERE status IN ('pending','shipped')——优化器往往无法把新条件下推到基表扫描阶段，导致先算出全部pending和shipped订单，再过滤时间，白白多扫几十万行。
这种失效特别容易发生在含SELECT *、UPPER()、CAST()或隐式类型转换的视图中。
- 视图里写
ON CAST(o.user_id AS CHAR) = u.id→o.user_id上的索引彻底失效 - 复合索引
(status, created_at)在视图层被截断为只用status，外部AND created_at > ...无法复用索引第二列 - 视图定义含
SELECT *，外层WHERE无法下推到基表，因为优化器不确定哪些列会被真正用到
嵌套超过3层后，优化器直接放弃代价估算
SQL Server硬限制10层嵌套，报Msg 319；PostgreSQL和MySQL虽无层数上限，但实际运行中，v1 → v2 → v3 → v4这种结构会让优化器主动跳过精确代价计算——它不再比较Hash Join和Nested Loop的成本，而是随机选一个，或者强制物化中间结果。
你看到EXPLAIN里MATERIALIZE节点占比超60%，或同一SQL两次执行计划完全不同（一次走索引，一次全表扫），基本就是嵌套失控的信号。
- 每多一层嵌套，元数据依赖链就拉长一截，
sys.dm_exec_cached_plans里的plan_handle关联性变弱，缓存命中率骤降 - CTE不是解药：如果CTE里用了
SELECT *或ORDER BY，它反而比原视图更易被强制物化 - 真正有效的扁平化，是把v3的定义抄进v4的
WITH子句，删掉v3这个中间层，减少解析时的展开跳数
死锁风险因视图隐藏加锁顺序
视图不持锁，但它决定执行路径，也就决定了InnoDB加锁顺序。如果视图定义是FROM orders JOIN users，而优化器实际选users为驱动表，加锁顺序就变成users → orders；但业务代码里另一处UPDATE users和UPDATE orders的顺序是反的，两个事务一并发，立刻形成循环等待。
SHOW ENGINE INNODB STATUS\G里能看到HOLDS THE LOCK(S) on orders，同时WAITING FOR THIS LOCK TO BE GRANTED on users——而你根本没在应用层显式写过这个顺序，全是视图封装惹的祸。
- ORM自动生成的
SELECT * FROM v_order_detail WHERE id = ?+ 后续UPDATE orders，等于在一个事务里走了两条不同锁路径 - 视图里
LEFT JOIN变INNER JOIN、OR条件被改写、甚至字段别名冲突，都可能让优化器临时切换连接算法，进而改变加锁粒度和顺序 - 调试时不能只看视图定义，必须用
EXPLAIN ANALYZE（PostgreSQL）或SET STATISTICS XML ON（SQL Server）抓真实执行流
复杂点不在语法对不对，而在你永远不知道优化器在“黑盒”里做了什么决定。越想靠视图抽象逻辑，越容易把性能和并发问题藏得更深。
