视图查询不走索引，根本原因是JOIN字段类型、字符集或排序规则不一致，或含非确定性函数及不当NULL处理，导致优化器无法使用索引。

视图查询不走索引，大概率是JOIN字段类型不一致

视图本身不存数据，它只是保存了一条SELECT语句。执行视图时，数据库会把视图定义“展开”成实际SQL再优化执行。如果视图里有JOIN，而关联字段类型不匹配（比如user_id INT vs log.user_id VARCHAR），优化器就无法用上索引——不是视图的问题，是底层JOIN失效了。

这种问题在MySQL中尤其隐蔽：你查视图没报错、有结果，但EXPLAIN显示type: ALL、key: NULL，rows预估爆炸，说明已经全表扫描了。

• 用SHOW CREATE TABLE分别查两张底表，比对JOIN字段的完整定义，包括TINYINT/INT、VARCHAR(20)/VARCHAR(50)、是否NOT NULL
• 特别注意从CSV/Excel导入或ETL脚本生成的表，id列常被建为VARCHAR，但业务代码里当数字用
• Oracle报ORA-01722、MySQL报ERROR 1267，基本可直接锁定类型不匹配

字符集或COLLATION不一致也会让索引“隐身”

即使两个字段都是VARCHAR，只要字符集或排序规则不同，MySQL仍会隐式转换。例如utf8mb4_general_ci和utf8mb4_0900_as_cs不兼容，JOIN时就会放弃索引。

PostgreSQL虽不靠collation做JOIN，但若视图定义里对字段用了LOWER()或LIKE，同样触发序列扫描；SQL Server中collation不一致还可能直接报错Cannot resolve collation conflict。

• 执行SHOW FULL COLUMNS FROM table_name LIKE 'field_name'，看Collation列是否完全一致
• 别只改CHARACTER SET，COLLATE必须同步修改，否则白忙活
• 临时验证可用CONVERT(field USING utf8mb4)，但这是饮鸩止渴——索引依然不生效，且执行计划不稳定

NULL值+类型混用，会让优化器彻底“猜错”连接策略

当JOIN字段含大量NULL，且类型又不一致时，优化器可能误判数据分布，放弃哈希连接（Hash Join）而选嵌套循环（Nested Loop），尤其在SQL Server和MySQL 5.7之前版本中明显。现象是视图查得慢、CPU打满，但单表查询都很快。

• 检查SELECT COUNT(*) FROM table WHERE field IS NULL，确认NULL比例是否超过10%
• 避免在ON条件里写t1.id = t2.id OR (t1.id IS NULL AND t2.id IS NULL)这类逻辑——它既破坏索引，又干扰优化器估算
• 如必须处理NULL，优先在应用层过滤，或用COALESCE(t1.id, -1) = COALESCE(t2.id, -1)并确保-1值在业务中不真实存在

视图定义含非确定性函数，会让执行计划“失忆”

视图里用了NOW()、GETDATE()、NEWID()或子查询，会导致每次执行逻辑不同。MySQL 8.0+的物化视图（实为查询重写）也可能因统计信息过期而走错路径；SQL Server中带SCHEMABINDING的视图若底表结构变更，元数据未刷新，也会查出旧数据。

• MySQL中跑EXPLAIN FORMAT=TREE SELECT * FROM your_view，看是否有MATERIALIZED字样，再对比EXPLAIN SELECT * FROM physical_table的key列
• SQL Server查sys.sql_modules：执行SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('your_view_name')，确认有没有非确定性函数
• PostgreSQL用\d+ your_view，留意是否标记security_invoker——这会影响行级安全策略的生效时机

视图不走索引，从来不是视图的锅。真正要盯死的，是那几处JOIN字段的类型、字符集、NULL处理逻辑，以及函数是否“确定”。这些地方差一个字节，优化器就敢把索引扔进回收站。