行级锁并发上限远高于表级锁，因前者仅锁定操作行而后者锁整张表；MyISAM全表锁、InnoDB行锁依赖索引，否则退化为表锁，间隙锁与MVCC进一步影响并发表现。
行级锁 vs 表级锁：锁粒度决定并发上限
MyISAM 一写全表锁死，InnoDB 只锁被 UPDATE/DELETE/INSERT ... ON DUPLICATE KEY UPDATE 触及的那几行。关键不是“有没有锁”，而是“锁多大范围”。
常见错误现象：SHOW PROCESSLIST 里大量线程卡在 Locked 状态；慢查询日志中反复出现 Waiting for table level lock；QPS 上不去但 CPU 和磁盘 I/O 都很低。
- MyISAM 的
INSERT、UPDATE、DELETE全部触发表级写锁，哪怕只改一行，整张表的读和写都得排队 - InnoDB 的行级锁依赖索引定位——必须走索引才能精准锁行；否则会退化为表级锁（比如
WHERE name LIKE '%abc%'没有用上索引） - 间隙锁（gap lock）和临键锁（next-key lock）会影响并发，尤其在
RANGE查询或唯一索引冲突时，不是所有“看起来不相关的行”都绝对互不干扰
MVCC 让读操作彻底绕开锁竞争
InnoDB 的读不阻塞写，根本原因不是“读不加锁”，而是它压根不用去争同一把锁——读走快照，写走当前版本，各看各的“平行宇宙”。
典型场景：电商详情页（高频 SELECT）和库存扣减（高频 UPDATE）同时发生，两者完全不互相等待。
-
SELECT默认是快照读（snapshot read），不加任何锁，只根据事务启动时刻生成的Read View去 Undo Log 中找可见版本 - 只有显式加锁的读才触发当前读（current read），比如
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE，这时才会和写操作争锁 - Undo Log 版本链由
DB_TRX_ID和DB_ROLL_PTR隐式维护，对业务 SQL 完全透明，但长事务会拖住旧版本清理，导致ibdata1膨胀或锁等待加剧
为什么 MyISAM 看似“快”却扛不住并发？
MyISAM 的所谓“快”，仅限于单线程、纯读、小数据量场景。它的 key_buffer_size 只缓存索引，数据还得靠 OS 文件缓存；而 InnoDB 的 innodb_buffer_pool_size 直接缓存数据页+索引页，热数据全在内存里，随机读就是一次指针跳转。
- MyISAM 的
COUNT(*)快是因为元数据硬编码，但加了WHERE就立刻变慢——它没 MVCC，也没行锁，只能全表扫描+逐行判断 - InnoDB 即使
COUNT(*)慢，也是因为真正在遍历索引树统计；但这反而说明它没偷懒，数据一致性有保障 - MyISAM 崩溃后无法自动恢复，需要手动
REPAIR TABLE，而 InnoDB 重启时靠redo log重放 +undo log回滚，5 秒内就能回到一致状态
真正影响 InnoDB 并发表现的几个硬参数
行级锁和 MVCC 是基础能力，但没调对参数，照样卡在半路。这些不是“可选优化”，而是高并发 OLTP 的运行底线。
-
innodb_buffer_pool_size至少设为物理内存的 60%–80%，低于此值会导致Innodb_buffer_pool_reads持续 > 10 次/秒，说明频繁落盘 -
innodb_lock_wait_timeout默认 50 秒太长，Web 应用建议设为 10–30 秒，避免一个慢事务拖垮整个连接池 -
innodb_file_per_table=ON必须开启，否则删表不释放空间，且无法单独对某张表做OPTIMIZE TABLE - 主键必须是自增整型；用 UUID 或字符串主键会导致页分裂、B+ 树深度增加、二级索引回表成本飙升——这不是并发问题，是底层存储结构崩了
innodb_buffer_pool_size 的联动效应：主键乱序会让 Buffer Pool 缓存命中率断崖下跌，再大的内存也救不回随机 I/O。 
