视图执行时会实时展开底层查询，若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 万行）JOINusers（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></association>），根本不会帮你检查基表索引。上线前光测功能不够，必须看 EXPLAIN + 锁状态，否则流量一上来，不是慢，是整个业务链路被锁住。
