视图查询不走索引，根本原因是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处理逻辑，以及函数是否“确定”。这些地方差一个字节，优化器就敢把索引扔进回收站。
