视图查询不走索引的根本原因是底层执行计划无法利用索引，主因包括JOIN字段类型不一致、字符集或排序规则不匹配、NULL处理不当、以及视图定义含GROUP BY/DISTINCT/CTE等触发强制物化，导致优化器放弃索引而全表扫描。
视图查询不走索引，不是视图本身“屏蔽”了索引，而是底层 SQL 执行时优化器根本没法用上索引——问题出在 JOIN 字段类型不一致、字符集或排序规则 mismatch、NULL 处理不当、或视图定义强制物化这几个硬伤上。
JOIN 字段类型不一致导致索引失效
这是最常见也最隐蔽的坑。视图里写 ON t1.user_id = t2.user_id，但一张表是 INT，另一张是 VARCHAR，MySQL 就会隐式转换，放弃索引。
- 用
SHOW CREATE TABLE table_name对比两张底表，逐字检查字段定义：类型（TINYINTvsINT）、长度（VARCHAR(20)vsVARCHAR(50)）、是否NOT NULL - 导入数据后生成的表，id 列常被建为
VARCHAR，但业务代码当数字用，一查就全表扫描 - 错误信息如
ERROR 1267（MySQL）或ORA-01722（Oracle）基本可直接锁定类型不匹配
字符集或 COLLATION 不一致让索引“隐身”
两个字段都是 VARCHAR，但 COLLATE utf8mb4_0900_as_cs 和 utf8mb4_general_ci 不兼容，JOIN 时照样不走索引。
- 执行
SHOW FULL COLUMNS FROM table_name LIKE 'field_name'，看Collation列是否完全一致 - 别只改
CHARACTER SET，COLLATE必须同步修改，否则白忙活 -
CONVERT(field USING utf8mb4)是临时验证手段，不能解决根本问题，且会让执行计划不稳定
视图定义含 GROUP BY / DISTINCT / 子查询触发物化
只要视图定义里出现 GROUP BY、DISTINCT、UNION、ORDER BY + LIMIT 或 CTE（WITH），优化器大概率放弃内联，先生成临时表再处理——此时基表索引顺序彻底失效。
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN (VERBOSE)（PostgreSQL）查执行计划，看到Materialize或Temp Table节点，就说明已物化 - 即使视图能内联，
GROUP BY a, b也必须严格匹配索引最左前缀；写成GROUP BY b, a或加WHERE c > '2024'都会让索引失效 - SQL Server 的索引视图是特例，需
SCHEMABINDING+ 唯一聚集索引 + 5 个会话选项全开，MySQL/PG 完全不支持
NULL 值混用 + 类型不一致干扰优化器估算
当 JOIN 字段含大量 NULL，又类型不一致时，优化器可能误判数据分布，放弃哈希连接，退化为嵌套循环，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在业务中不真实存在
真正要盯住的不是“视图有没有索引”，而是执行计划里 key 是否为 NULL、type 是否掉到 ALL、Extra 是否出现 Using temporary——这些信号比任何经验都准。一旦物化发生，物理顺序就没了，再好的聚簇索引也救不回来。
