高并发下应避免使用myisam而选用innodb，因myisam仅支持表级锁易导致写入卡死，innodb行级锁更适配并发场景，但需合理配置buffer_pool_size、刷盘策略及事务批量处理以发挥性能。
高并发下别用 MyISAM，INSERT 和 UPDATE 会直接卡死
MyISAM 只支持表级锁，哪怕你只更新一行，整张表都会被锁住。在并发写入稍高的场景（比如每秒 20+ 次 INSERT 或 UPDATE），请求会排队堆积，SHOW PROCESSLIST 里能看到大量 Locked 状态。InnoDB 默认行级锁，只要不是更新同一行，彼此互不干扰。
实操建议：
- 压测时用
sysbench跑oltp_write_only场景，对比 50 并发下的平均响应时间和失败率——MyISAM 失败率常飙升到 15%+，InnoDB 通常稳定在 0.1% 以内 - 如果业务真有“纯读+批量导入”场景（如日志归档表），可考虑 MyISAM，但必须确保导入期间无任何查询或更新
- MyISAM 的
CHECK TABLE和REPAIR TABLE在高并发下可能触发长时间锁表，InnoDB 的崩溃恢复由innodb_force_recovery控制，更可控
innodb_buffer_pool_size 设太小，InnoDB 也扛不住高并发
InnoDB 性能严重依赖缓冲池。默认值通常是 128MB，但在 16GB 内存的服务器上，设成 12GB 都不算激进。如果这个值远小于活跃数据集大小，每次查询都得从磁盘读页，SHOW ENGINE INNODB STATUS 里会频繁出现 Buffer pool hit rate 低于 950/1000 的告警。
实操建议：
- 用
SELECT (SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_POOL_PAGES_DATA) * @@innodb_page_size / 1024 / 1024 AS mb_used;估算实际使用量 - 线上环境建议设为物理内存的 50%–75%，但不要超过
innodb_buffer_pool_instances× 1GB（避免单实例过大影响并发访问） - 调整后必须重启 MySQL，且首次启动会慢——因为要预热缓冲池，可通过
innodb_buffer_pool_load_at_startup=ON加速
高并发下 autocommit=1 和短事务不是万能解药
很多人以为只要开 autocommit、每个 INSERT 单独提交，InnoDB 就一定快。但若频繁执行小事务，innodb_flush_log_at_trx_commit=1（默认）会导致每次提交都刷盘，IOPS 直接打满。而设成 2 或 0 虽提升吞吐，却牺牲持久性：机器掉电可能丢 1 秒事务。
实操建议：
- 写密集型服务（如计数器、埋点）可临时设
innodb_flush_log_at_trx_commit=2+sync_binlog=0，但必须接受极端情况下少量数据丢失 - 批量插入优先用
INSERT INTO ... VALUES (...), (...), (...)代替多条单行INSERT，减少事务开销 - 避免在循环里反复
START TRANSACTION/COMMIT，改用显式事务包裹一批操作（例如 100 条一组）
唯一索引冲突和死锁，InnoDB 并发越高越容易暴露
高并发下两个线程同时 INSERT 同一个唯一键（比如用户注册用手机号做唯一索引），InnoDB 会因间隙锁（gap lock）产生死锁，错误信息是 Deadlock found when trying to get lock; try restarting transaction。这不是配置问题，是 MVCC + 索引机制的必然表现。
实操建议：
- 应用层捕获
1213错误码并重试，但重试间隔要加随机抖动，否则所有线程同步重试会再次撞上死锁 - 对强一致性要求不高的场景（如优惠券领取），可用
INSERT IGNORE或ON DUPLICATE KEY UPDATE规避异常抛出 - 监控
Innodb_row_lock_waits和Innodb_deadlocks这两个状态变量，突增说明锁竞争已成瓶颈
真正难调的从来不是引擎选型，而是把 InnoDB 的锁行为、刷盘策略、缓冲池水位和业务写模式对齐。很多“高并发变慢”的问题，最后发现是某张表没建好索引，导致 UPDATE 扫全表加了意向锁，把整个库拖垮。
