先说一个核心判断：在数据库优化实践中，视图关联大表时，索引并非锦上添花，而是不可或缺的刚性需求。很多开发者误以为视图只是保存SQL定义的快捷方式，用起来很方便，结果一旦系统遭遇高并发场景，整个业务链路被锁冲突拖垮，连最基本的INSERT操作都无法执行，才意识到问题根源出在哪里。
视图本身并不存储实际数据，每次执行时都会将背后的SQL定义实时展开。如果关联字段缺少索引，JOIN操作就会触发全表扫描并附加临键锁（Next-Key Lock）。在MySQL默认的RR（可重复读）隔离级别下，这种操作等效于对整张表施加了逻辑锁——并发写入操作即刻被阻塞。从锁机制的视角看，其危害远比一般的慢查询更为致命。
视图执行的本质是SQL重写，缺失索引等同于全表裸跑
视图的本质究竟是什么？它仅仅是存储了一条SELECT语句的定义。执行SELECT * FROM my_view时，MySQL会将视图定义中的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万 - 只有两张表的关联字段都建立了索引，才能充分发挥嵌套循环连接（Nested Loop Join）的高效路径
最后指出一个容易被忽视的陷阱：ORM框架自动生成的视图类查询（比如GORM的Preload、MyBatis的
