InnoDB是MySQL事务型应用的默认选择，因其完整支持ACID、行级锁和外键；若未显式指定ENGINE=InnoDB或配置不当，事务将静默失效。
为什么 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 写得再好，也会因频繁页换入换出卡顿。
常见配置陷阱：
Yes!Sun基于PHP+MYSQL技术，体积小巧、应用灵活、功能强大，是一款为企业网站量身打造的WEB系统。其创新的设计理念，为企业网的开发设计及使用带来了全新的体验：支持前沿技术：动态缓存、伪静态、静态生成、友好URL、SEO设置等提升网站性能、用户体验、搜索引擎友好度的技术均为Yes!Sun所支持。易于二次开发：采用独创的平台化理念，按需定制项目中的各种元素，如：产品属性、产品相册、新闻列表
- 在 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。
