myisam 表级锁导致写操作串行化，无法利用多核cpu并行能力，qps受限；innodb行锁+mvcc结合合理索引与短事务才能真正发挥多核性能。
MyISAM 表级锁直接阻塞并发写入
MyISAM 对 UPDATE 或 DELETE 操作默认加整表锁，哪怕只改一行，其他写请求也得排队。多核 CPU 有并行能力，但 MyISAM 的锁机制让写操作无法真正并行——CPU 核心空转等待，QPS 上不去。
常见错误现象：Waiting for table metadata lock 频繁出现，尤其在订单、日志类高频写场景下；SHOW PROCESSLIST 中大量线程卡在 Updating 或 Deleting 状态。
- 即使服务器是 32 核 CPU，MyISAM 写吞吐量可能还不如单核跑 InnoDB
- MySQL 5.6 之后虽支持部分并发读，但写仍是串行瓶颈，不因 CPU 核数增加而改善
- 主从复制中，从库回放也是单线程（除非启用
slave_parallel_workers，但 MyISAM 不支持并行回放）
InnoDB 行锁 + MVCC 才能压满多核资源
InnoDB 的行级锁和多版本并发控制（MVCC）允许不同事务操作不同行时互不阻塞。只要 SQL 走索引、事务够短，多个写请求就能真正分发到不同 CPU 核心上执行。
但要注意：没走索引的 UPDATE 或 DELETE 会升级为表锁，效果等同 MyISAM —— 这点常被忽略。
- 用
EXPLAIN确认type是ref/range，不是ALL - 避免在大表上执行无 WHERE 条件或模糊前缀的更新（如
LIKE '%abc'） - 事务别拖太久，否则锁持有时间长，抵消行锁优势
MyISAM 索引与数据分离加剧 CPU 缓存压力
MyISAM 把索引缓存在 key_buffer 中，数据靠操作系统页缓存管理。这种分离导致一次查询可能触发两次内存访问（先查索引定位行号，再读数据文件），CPU 缓存局部性差，多核争抢 L3 缓存更明显。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
InnoDB 则把数据和索引一起缓存在 innodb_buffer_pool，B+ 树遍历过程中节点和记录都在同一内存区域，缓存命中率高，对多核 CPU 更友好。
-
key_buffer_size只管索引，innodb_buffer_pool_size管全部热数据，后者利用率通常更高 - MyISAM 在 SSD 上表现尚可，但在 NVMe + 多核场景下，I/O 并发能力反而被锁机制压制
- 没有事务日志（binlog 是 server 层的），崩溃恢复慢，重启后首次查询抖动大，影响 CPU 调度稳定性
现代 MySQL 版本已基本放弃 MyISAM 优化
MySQL 8.0 默认禁用 MyISAM 系统表（mysql.* 全部转 InnoDB），官方文档明确建议业务表不要用 MyISAM。所有新特性（如原子 DDL、并行查询、资源组 CPU 绑定）都只适配 InnoDB。
迁移存量 MyISAM 表前，务必先运行：SHOW CREATE TABLE `table_name` 查引擎，再用：ALTER TABLE `table_name` ENGINE=InnoDB 切换。
- 切换前检查磁盘空间：InnoDB 表体积通常比 MyISAM 大 10%–30%，因多了事务头、undo 日志等开销
- 大表建议在低峰期执行，或用
pt-online-schema-change避免锁表 - 切完立刻验证：
SELECT COUNT(*)和SELECT * FROM table LIMIT 1是否正常，防止隐式转换失败
MyISAM 在多核环境下的扩展性短板，本质是锁粒度与内存访问模式不匹配现代硬件，不是调参能绕过的。真正要发挥多核性能，必须从引擎选型开始就选 InnoDB，并确保索引设计和 SQL 写法不退化成“伪行锁”。
