索引没建对，事务照样卡死
事务本身不解决性能问题，它只保证一致性；如果事务里执行的
UPDATE或
SELECT ... FOR UPDATE扫描了全表，锁住成千上万行，那阻塞、超时、死锁就都来了。索引是事务高效执行的前提，不是可选项。
常见错误：在
WHERE条件字段上没建索引，却指望事务“自动变快”。比如：
START TRANSACTION; UPDATE orders SET status = 'shipped' WHERE user_id = 123 AND created_at > '2024-01-01'; COMMIT;如果
user_id和
created_at没联合索引，MySQL 可能走
user_id单列索引后回表过滤时间，也可能直接全表扫描——后者会让事务持有大量行锁甚至升级为表锁。 写事务前先
EXPLAIN对应的
SELECT或
UPDATE，确认是否走了索引、是否用了
type=range或更好 复合条件优先建联合索引，顺序按「等值查询字段在前、范围查询字段在后」，例如
(user_id, created_at)而非
(created_at, user_id)避免在索引字段上用函数或隐式类型转换，比如
WHERE DATE(created_at) = '2024-01-01'会跳过索引
事务中修改数据时，索引维护开销不能忽略
每次
INSERT/
UPDATE/
DELETE都要同步更新所有相关索引，索引越多、越宽（字段多、字符长），事务的写入延迟和锁持有时间就越长。这不是理论，是 InnoDB 的实际行为。
典型场景：一张日志表有 8 个二级索引，但业务只按
trace_id查询；结果每次写入都要维护 8 棵 B+ 树，事务平均耗时翻倍，还容易因锁等待触发
Lock wait timeout exceeded。 删掉长期不用的二级索引，用
information_schema.STATISTICS或
sys.schema_unused_indexes（MySQL 8.0+）辅助识别 字符串索引慎用
FULLTEXT或长前缀（如
content(255)），改用生成列 + 索引更可控 高频更新的字段尽量别建索引，比如
updated_at单独建索引，除非你真要用它查“最近更新的记录”
长事务 + 非唯一索引 = 隐形死锁高发区
InnoDB 在非唯一索引上加锁时，会锁定查找路径上的“间隙（gap）”，而不仅是匹配到的记录。如果两个事务先后执行相似的
SELECT ... FOR UPDATE且没走唯一索引，很容易互相等待对方释放 gap 锁，形成死锁。
例如：
SELECT * FROM products WHERE category = 'electronics' ORDER BY price LIMIT 1 FOR UPDATE;若
category是非唯一索引，InnoDB 会锁住满足条件的记录及其前后间隙；并发执行时，不同事务可能锁住重叠的 gap 区域，触发死锁检测并回滚其中一个。 尽量让关键事务走唯一索引（如主键、
UNIQUE约束字段），减少 gap 锁范围 避免在事务中执行无明确目标的
LIMIT查询加锁，尤其是非唯一条件下的“取第一条”逻辑 用
innodb_lock_wait_timeout控制等待上限（默认 50 秒），但治标不治本；根本解法还是缩小锁粒度
READ COMMITTED 隔离级别下，索引仍影响 MVCC 版本链遍历效率
即使不加锁，
READ COMMITTED下的
SELECT也要遍历 undo log 版本链找可见版本。如果扫描行数多（因为没索引），就要比对更多版本，CPU 和 buffer pool 压力都会升高。
现象：监控看到
Innodb_buffer_pool_read_requests很高，但
Innodb_buffer_pool_reads不高，说明命中率 OK，但 CPU 使用率异常飙高——很可能就是 MVCC 遍历开销过大。 不要以为
READ COMMITTED就可以不建索引；它只是不加 gap 锁，不代表不扫描、不比对版本 对频繁被事务读取的字段，确保查询能通过索引快速定位，而非靠 server 层过滤 大表分页慎用
OFFSET，它本质是“跳过 N 行”，没索引支撑时等于强制遍历，MVCC 开销随偏移量线性增长
索引和事务的交界处，最易被忽略的是“锁的范围”和“版本遍历的成本”——这两者都不报错，但会让系统在高并发下突然变慢、超时、死锁。优化必须从语句执行计划出发，而不是只盯着隔离级别或索引数量。
