InnoDB高并发写入性能优于MyISAM的根本原因是行级锁降低资源竞争粒度，但仅当SQL走索引、开启事务且隔离级别合理时生效；否则行锁退化为表锁，实际并发能力接近甚至低于MyISAM。
高并发写入场景下InnoDB的行级锁只在走索引时生效
InnoDB的并发优势不是默认开启的魔法开关，它依赖SQL实际执行路径。如果WHERE条件没命中索引，比如WHERE name LIKE "%admin"或WHERE DATE(create_time) = '2026-05-11'，InnoDB会退化为全表扫描+逐行加锁，效果等同于MyISAM的表级锁。
真正触发行级锁的关键是：主键等值查询（WHERE id = 100）、有索引的范围查询（WHERE status = 1），且事务已显式开启（BEGIN）。
- 用
EXPLAIN确认type字段不是ALL或index - 避免在索引列上使用函数、隐式类型转换、左模糊匹配
- 高频更新同一字段（如
status）可能引发热点行争用，需结合业务拆分或引入缓存
MyISAM在写操作中根本无法规避表级锁
MyISAM对任何INSERT/UPDATE/DELETE都直接申请整张表的WRITE LOCK，期间所有其他写请求排队，读请求也被阻塞（除非启用concurrent_insert且仅限尾部追加）。
这意味着两个事务分别更新id=1和id=10000，仍会互相等待；一个慢SELECT正在执行，所有写操作必须等它结束。
- 没有事务回滚能力，写中断后表可能处于中间状态，必须人工运行
REPAIR TABLE -
REPAIR TABLE本身可能丢数据；更严重损坏需停服用myisamchk，期间表完全不可用 - 2026年起MySQL已默认禁用MyISAM，新实例建表不指定引擎时不再回退到MyISAM
InnoDB的并发吞吐还取决于事务控制方式
即使用了InnoDB，autocommit=1（默认）下每个SQL都是独立事务，redo log频繁刷盘，吞吐打折；而批量写入不包裹BEGIN/COMMIT，会导致undo log暴涨、锁持有时间过长。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 高频单行更新建议调低
innodb_lock_wait_timeout至5~10秒，避免Lock wait timeout exceeded掩盖真实瓶颈 - 批量导入应显式用
BEGIN/COMMIT包裹，单事务控制在≤ 5000行 - 检查
innodb_flush_log_at_trx_commit设置：线上OLTP建议保持1（安全），ETL类任务可临时设为2或0（牺牲部分持久性换吞吐） - 二级索引过多会显著拖慢写入——每次
INSERT都要更新所有索引树
别只看CREATE TABLE里的ENGINE=InnoDB就以为万事大吉
很多“InnoDB变慢”的案例，根源不在引擎本身，而在SQL写法或配置失配。例如：EXPLAIN显示type=ALL却误以为走了索引；未调优日志刷盘策略；或一张表堆了七八个二级索引。
MyISAM的所谓“读快”也常是假象：COUNT(*)快是因为缓存了元数据，但带WHERE条件时两者都要走索引扫描，性能差异可忽略；且该缓存值在并发写入或主从复制下可能不准。
现实里几乎不存在纯无条件COUNT(*)需求，真有这类统计，应该用单独计数表或Redis缓存，而不是靠引擎“作弊”。
