视图索引失效的根本原因是谓词未下推至基表扫描节点，而是停留在上层Filter中；典型诱因包括视图含GROUP BY、DISTINCT、子查询、表达式或JOIN字段类型/COLLATION不一致。
视图无法利用外层主查询传入的索引条件，根本原因不是“视图拒绝接收”，而是视图展开后，WHERE 条件未能落到基表扫描节点的 Access Predicates 中——它被卡在了上层 Filter 节点，索引自然失效。
视图展开后谓词没下推到基表扫描节点
数据库执行 SELECT * FROM v_user WHERE id = 123 时，优化器会先把 v_user 替换为它的定义（比如 SELECT name, email FROM users WHERE status = 1），最终生成类似：
SELECT name, email FROM users WHERE status = 1 AND id = 123
但这个“最终 SQL”只是逻辑等价，不等于物理执行路径。如果视图定义含 GROUP BY、DISTINCT、子查询或表达式，优化器可能提前物化中间结果，导致 id = 123 只能在物化后的临时集上过滤，而非直接作用于 users 表扫描。
- 检查执行计划：基表那一行的
Extra（MySQL）或Actual Number of Rows+Filter（SQL Server/PostgreSQL）是否显示“大量扫描后才过滤” - 关键指标：若
Access Predicates为空，而Filter里有你的条件，说明谓词没下推 - 典型诱因包括视图定义中用了
UPPER(name)、COALESCE(email, '')或嵌套(SELECT ...)
视图定义含子查询或派生表，强制物化中间结果
MySQL 尤其明显：只要视图定义里出现 SELECT ... FROM (SELECT ...) AS t 这类结构，优化器大概率会先执行内层 SELECT 并缓存结果（即“物化”），外层的 WHERE 就再也触碰不到原始索引。
- 例如视图
CREATE VIEW v_active AS SELECT id, name FROM (SELECT * FROM users WHERE deleted = 0) t，后续查SELECT * FROM v_active WHERE id = 456就无法触发users.id索引 - EXPLAIN 中会看到
type: ALL、key: NULL，且Extra显示Using where（非Using index condition） - 解决方向：把子查询逻辑上提，改写为直接 JOIN 或 WHERE，避免视图里藏派生表
JOIN 字段类型或 COLLATION 不一致，让索引“不可见”
视图常涉及多表 JOIN，如果外层查询的过滤条件落在 JOIN 后的字段上（如 v_order_detail.product_id），而该字段实际来自 orders.id INT 和 products.code VARCHAR 的关联，类型不匹配会让整个连接路径放弃索引。
- 用
SHOW FULL COLUMNS FROM table_name LIKE 'col_name'对比两边字段的完整类型、Collation、是否NOT NULL - 常见坑：
INTvsVARCHAR、utf8mb4_general_civsutf8mb4_0900_as_cs、隐式转换如WHERE product_id = '123'（字段是 INT） - 修复后必须更新统计信息：
UPDATE STATISTICS（SQL Server）或ANALYZE TABLE（MySQL）
真正卡住性能的，往往不是视图本身，而是它展开后那条“看不见的 SQL”——你得把它揪出来看执行计划，而不是只盯着视图定义改来改去。尤其当视图被嵌套调用、又带参数时，谓词下推失败几乎是默认行为，别指望优化器自动帮你绕过。
