为什么 InnoDB 是事务型应用的默认选择
MySQL 中只有
InnoDB存储引擎完整支持 ACID 事务、行级锁和外键约束。如果你在
CREATE TABLE时没显式指定
ENGINE=InnoDB，而服务器启用了
skip-innodb或默认引擎是
MyISAM，那所谓“事务”实际不会生效——
COMMIT和
ROLLBACK只是静默忽略，连警告都不报。
验证当前表引擎：
SHOW CREATE TABLE orders;确保输出中包含
ENGINE=InnoDB；若为
MyISAM或
MEMORY，需立刻迁移：
ALTER TABLE orders ENGINE=InnoDB;
MyISAM表执行
BEGIN后仍能被其他会话立即读写，根本无事务隔离可言
MEMORY引擎不支持事务，且重启后数据全丢，仅适合临时缓存 从 MySQL 5.7 起，
innodb_file_per_table=ON应为标配，否则所有表共用一个
ibdata1，删除大表后空间无法回收
如何通过事务粒度与隔离级别平衡并发与一致性
默认的
REPEATABLE READ隔离级别在高并发更新场景下容易引发间隙锁（
Gap Lock）冲突，导致看似无关的插入被阻塞。比如对
price BETWEEN 100 AND 200加锁，InnoDB 会锁住这个范围内的所有间隙，哪怕该价格区间当前为空。
实操建议：
读多写少且允许幻读的场景（如报表统计），可降级为READ COMMITTED：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;它禁用间隙锁，提升并发插入能力 避免在事务中执行耗时操作（如调用外部 HTTP 接口、生成 PDF），否则锁持有时间过长，直接拖垮吞吐 批量更新尽量用单条
UPDATE ... WHERE IN (...)替代循环执行多条
UPDATE，减少事务开销和锁竞争
关键参数调优：buffer pool 与日志刷盘策略
innodb_buffer_pool_size是影响事务性能最直接的参数。它决定多少热数据能常驻内存，避免频繁磁盘 I/O。若该值小于活跃数据集大小，即使 SQL 写得再好，也会因频繁页换入换出卡顿。
常见配置陷阱：
在 64GB 内存的服务器上设innodb_buffer_pool_size = 50G，看似合理，但未预留足够内存给 OS 缓存、连接线程栈和临时表，反而触发系统 OOM Killer 杀进程
innodb_log_file_size过小（如默认 48MB）会导致频繁 checkpoint，写密集场景下
fsync成瓶颈；建议设为 1–2GB，但修改前必须停库并删除旧日志文件
innodb_flush_log_at_trx_commit = 1保证每次
COMMIT都刷盘，安全但慢；若可接受秒级数据丢失风险，可设为
2（每秒刷一次）或
0（由 OS 控制，最不安全）
死锁排查与索引设计对锁范围的影响
死锁不是 bug，而是并发事务争夺资源的必然现象。InnoDB 会自动检测并回滚代价小的事务，但高频死锁说明索引或 SQL 逻辑有问题。
典型诱因：
没有覆盖索引的UPDATE语句，导致扫描全表或大量行，锁住不该锁的记录 多个事务以不同顺序更新同一组主键（如事务 A 先改 id=5 再改 id=3，事务 B 反之），极易死锁 使用
SELECT ... FOR UPDATE但 WHERE 条件未命中索引，升级为表锁
查死锁日志：
SHOW ENGINE INNODB STATUS\G关注
LATEST DETECTED DEADLOCK段，重点看
TRANSACTION的
lock_mode和
lock_trx_id，结合业务逻辑判断是否可通过调整 SQL 执行顺序或添加索引规避。
真正难处理的是隐式锁转换——比如唯一索引冲突时，InnoDB 会在插入前加意向锁，若此时另一事务正对该唯一键做
SELECT ... FOR UPDATE，就可能形成隐蔽死锁链。这类问题必须靠
EXPLAIN确认执行计划 + 慢日志定位热点 SQL。
