在SQL视图中进行大表关联时为什么必须确保关联键存在索引？

视图执行时会实时展开底层查询，若JOIN关联字段无索引，则触发全表扫描与临键锁，在RR隔离级别下等效逻辑锁表，导致并发写入卡死；EXPLAIN中type=ALL或key=NULL即为铁证，且MySQL不支持在视图上建索引。

因为视图本身不存数据，执行时会实时展开底层查询；如果关联字段没索引，JOIN 就会触发全表扫描 + 临键锁，在 RR 隔离级别下等效“逻辑锁表”，并发写入直接卡死。

视图执行本质是重写 SQL，不走索引就等于裸跑

视图只是保存了一条 SELECT 语句的定义，SELECT * FROM my_view 实际等价于把视图定义里的 SQL 拆开、合并、重写后执行。它不会缓存结果，也不会自动给基表字段加索引。哪怕视图里只查两列，只要 JOIN 条件字段（比如 t1.user_id = t2.id）在 t2 上没索引，优化器照样得对 t2 做全表扫描。

• EXPLAIN 看到 type: ALL 或 key: NULL 就是铁证
• 即使视图加了 WHERE 过滤（如 WHERE t2.status = 'active'），只要 t2.status 没索引，照样扫全表
• MySQL 不会在视图上建索引——CREATE INDEX ON my_view(...) 是语法错误

大表关联没索引，锁表现象比慢查询更致命

很多人只盯着“查询慢”，但更危险的是锁扩散。InnoDB 的锁只加在索引上，没索引就只能退化为逐行扫描+加临键锁（Record Lock + Gap Lock）。尤其在 RR 隔离级别下，全表扫描会锁住主键索引的所有间隙，包括 (−∞, min) 和 (max, +∞)。

• 两个事务同时执行 SELECT ... FROM orders o JOIN users u ON o.user_id = u.id，而 users.id 有主键索引但 users.status 没索引 → 扫描 users 时锁所有间隙
• 第三个事务想 INSERT INTO users 新用户？直接被阻塞，不管新用户的 status 是什么值
• SHOW ENGINE INNODB STATUS 里能看到大量 LOCK_MODE: X locks gap before rec

小表驱动大表的前提，是两张表的关联字段都有索引

“小表驱动大表”能提速，但前提是驱动表和被驱动表的 JOIN 字段都命中索引。否则无论谁当驱动表，内层表都得全表扫一遍，总扫描行数 = 小表行数 × 大表行数。

• 假设 orders（100 万行）JOIN users（10 万行），orders.user_id 有索引但 users.id 没索引 → 还是得对 users 扫 100 万次
• 反过来，users.id 有索引但 orders.user_id 没索引 → orders 全表扫描，每次用 users.id 索引快速定位，总扫描行数 ≈ 10 万 × log₂(10 万) ≈ 170 万
• 两边都有索引，才真正实现 NLJ（Nested Loop Join）的高效路径

最常被忽略的一点：ORM 自动生成的视图类查询（比如 GORM 的 Preload、MyBatis 的 <association>），根本不会帮你检查基表索引。上线前光测功能不够，必须看 EXPLAIN + 锁状态，否则流量一上来，不是慢，是整个业务链路被锁住。