InnoDB 和 MyISAM 的锁机制差异直接影响并发写入能力
MySQL 存储引擎对并发性能的影响是实质性的，不是理论上的。核心区别在于锁粒度和事务支持：InnoDB 默认行级锁 + MVCC，MyISAM 只有表级锁且不支持事务。
这意味着在高并发写场景下，MyISAM 一旦执行
UPDATE或
INSERT，整张表被锁定，其他写操作必须排队；而 InnoDB 通常只锁涉及的行，其余行仍可并发修改。 读多写少、无事务需求的静态数据（如配置表），MyISAM 的轻量级锁可能略快，但实际极少成为优势 只要存在任何
UPDATE/
DELETE混合操作，MyISAM 的并发吞吐会断崖式下降 InnoDB 的
autocommit=1下每个语句自动成事务，看似简单，但隐式开启锁和日志写入，需关注
innodb_flush_log_at_trx_commit对延迟的影响
并发写入瓶颈常出在 InnoDB 的自增主键与聚簇索引设计上
很多人以为换用 InnoDB 就一劳永逸，但实际高并发插入时，
AUTO_INCREMENT锁和聚簇索引的页分裂会成为新瓶颈。
InnoDB 在插入新记录时，若主键非递增（比如 UUID），会导致数据物理位置随机写入，频繁触发 B+ 树页分裂和缓冲池淘汰；而自增主键虽顺序写入友好，但多个事务同时申请下一个 ID 时，会竞争
auto-inc lock（一种表级锁）。 使用
innodb_autoinc_lock_mode=2（交错模式）可解除大部分插入并发限制，前提是 binlog 格式为
ROW避免在高频插入表中用
VARCHAR(255)作主键，即使业务逻辑允许，也应坚持
BIGINT UNSIGNED AUTO_INCREMENT批量插入优于单条循环插入，但要注意
max_allowed_packet和事务大小——过大的事务会拖慢
undo log清理和锁持有时间
连接数、事务隔离级别和长事务会放大存储引擎的并发压力
引擎本身不决定并发上限，但它对上层资源的消耗方式决定了系统能承载多少并发。InnoDB 的每条活跃连接都对应内存中的事务结构、锁信息、MVCC 版本链，这些加起来比 MyISAM 消耗多得多。
例如设置
transaction_isolation = 'REPEATABLE-READ'后，一个未提交的事务会让 InnoDB 保留所有被它读过的旧版本数据，直到事务结束；如果有个事务持续 10 分钟没提交，
purge thread就无法清理这些版本，
undo log膨胀，最终拖慢整个实例。
wait_timeout和
interactive_timeout必须设合理值（如 300 秒），否则空闲连接长期占用事务上下文 应用层应避免“先查再改”模式（即
SELECT ... FOR UPDATE后隔几秒才
UPDATE），这等于人为制造长事务 监控
INFORMATION_SCHEMA.INNODB_TRX表，重点关注
TRX_STATE = 'RUNNING'且
TRX_STARTED时间过久的记录
不要忽略 buffer pool 和 redo log 配置对并发响应的实际影响
并发性能不只是“能不能同时处理”，更是“能不能快速响应”。InnoDB 的
innodb_buffer_pool_size决定热数据是否常驻内存；而
innodb_log_file_size和
innodb_log_files_in_group共同决定 redo log 循环写入的吞吐容量。
典型误配是：buffer pool 过小导致频繁磁盘读，或 redo log 总大小不足（如仅 48MB），在大批量写入时触发
checkpoint频繁刷脏页，造成 I/O 尖峰和 SQL 延迟突增。 buffer pool 建议设为物理内存的 50%–75%，但需给 OS 和其他进程留足空间（至少 2GB） redo log 总大小建议 ≥ 4GB（例如
innodb_log_file_size = 2G,
innodb_log_files_in_group = 2），尤其在 SSD 环境下效果明显 调整 redo log 大小需停机，且不能直接改配置重启——要先
SET GLOBAL innodb_fast_shutdown = 0，再关闭 MySQL，重命名旧 log 文件，再启动 真正卡住并发的，往往不是引擎选型本身，而是自增锁争用、长事务滞留、redo log 频繁 checkpoint 这些细节。它们不会报错，但会让 QPS 上不去、延迟毛刺不断，而且问题现象分散，容易误判为网络或应用层问题。
