InnoDB并发读写能力远强于MyISAM，根本原因在于其行锁机制与事务模型协同应对高并发压力；MyISAM表锁+无事务导致写操作阻塞所有读写，易引发阻塞雪崩。
InnoDB 的并发读写能力远强于 MyISAM，根本原因不在“锁粒度”本身，而在锁机制与事务模型如何协同应对真实业务压力——MyISAM 表锁 + 无事务，在高并发写入时会快速形成阻塞雪崩。
为什么 MyISAM 在并发写入时会卡死
MyISAM 对任何写操作（INSERT、UPDATE、DELETE）都强制加表级写锁，且该锁会阻塞所有后续的读和写请求。即使只更新一行，整张表不可读不可写。
- 多个
UPDATE同时执行？后到的全部排队，等待前一个释放表锁 - 有长查询正在执行
SELECT？写操作必须等它结束；反之，一个慢UPDATE也会让所有读请求挂起 - 写优先级默认高于读，所以读请求可能被长期饿死，尤其在混合负载下
- 没有事务回滚能力，一旦写中断（如网络断开），表可能处于中间状态，需人工修复
InnoDB 行锁不是万能解药，但它是可调优的起点
InnoDB 的行级锁只在语句命中索引时生效；若 WHERE 条件没走索引，实际会升级为表锁——这点常被忽略。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 用
EXPLAIN确认UPDATE或DELETE是否走了主键或唯一索引；非唯一二级索引可能触发间隙锁（Gap Lock），扩大锁定范围 - 避免
SELECT ... FOR UPDATE后再UPDATE，改用原子操作如UPDATE t SET cnt = cnt + 1 WHERE id = ? - 高并发更新同一字段（如状态列）时，即使走索引，也可能因热点行争用导致大量
Lock wait timeout exceeded错误 -
innodb_lock_wait_timeout默认 50 秒，线上建议调低至 5~10 秒，让失败更快暴露，而非无限等待
事务开销才是 InnoDB 并发写入的真实瓶颈
每条 INSERT 或 UPDATE 背后是 redo log 写入、undo log 记录、binlog 刷盘、索引 B+ 树分裂 —— 这些成本在单条语句中无法摊薄。
-
autocommit=1（默认）下，每个 SQL 都是独立事务，日志刷盘频繁，吞吐直接打折 - 批量写入时，用
START TRANSACTION包裹多条语句，控制事务大小（建议 ≤ 5000 行），避免 undo 日志暴涨 -
innodb_flush_log_at_trx_commit = 2可大幅提升写入速度（崩溃最多丢 1 秒数据），但需确认业务可接受此风险 - 每个额外索引都会成倍增加写开销；高频写表应精简索引，非核心查询可交由 ES 或物化视图承担
别只盯着引擎选型，先看你的查询是否真的需要 MyISAM
MyISAM 唯一明显优势只剩 COUNT(*) 无条件统计和全文索引（但仅限英文/分词明确场景）。其他所谓“读快”，在真实 OLTP 场景中几乎不成立。
-
COUNT(*)慢？InnoDB 下加WHERE条件并利用二级索引（如WHERE status > 0）可跳过聚簇索引扫描 - 需要全文搜索？MySQL 5.6+ 的 InnoDB 已支持
FULLTEXT，且中文分词可对接ngram插件 - 备份恢复快？Percona XtraBackup 对 InnoDB 是热备，MyISAM 表锁期间无法保证一致性
- GIS 数据？若真重度依赖空间查询，再考虑 MyISAM；否则多数地理围栏类逻辑可在应用层或 PostGIS 中完成
真正卡住并发写的，往往不是引擎本身，而是“用行锁的方式干着表锁的事”：比如全表扫描更新、共享热点主键、事务里混着 RPC 调用。优化得从 SQL 写法和事务边界开始，而不是换引擎。
