MyISAM表锁痕迹可通过慢查询日志中同表SELECT耗时突增且紧随写操作、多查询Query_time偏高但执行计划简单等间接信号识别；需结合SHOW PROCESSLIST的Locked状态、INFORMATION_SCHEMA确认引擎，并排查key_buffer_size过小导致的I/O误判。
怎么看慢查询日志里 MyISAM 的表锁痕迹
MyISAM 不支持行锁，所有写操作（INSERT、UPDATE、DELETE）都会触发整表锁定，而慢查询日志本身不直接记录“锁等待时长”，但能暴露间接信号：大量相同表的 SELECT 查询耗时突增，且紧随其后出现 INSERT 或 UPDATE；或者同一张表的多个查询 Query_time 普遍偏高（比如 >1s），但执行计划简单（无全表扫描、无大排序），说明瓶颈不在 SQL 本身，而在等待锁。
实操建议：
- 开启慢查询日志时必须设置
long_query_time = 0（或极低值），否则短于阈值的锁等待会被过滤掉 - 配合
log_queries_not_using_indexes = ON，辅助识别本可走索引却因锁阻塞而退化为慢查的SELECT - 用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log聚合统计，重点关注Count高、Time稳定在 200–500ms 区间的同表SELECT—— 这往往是被写操作反复阻塞的典型特征
如何确认是 MyISAM 表锁而非其他原因
仅靠慢日志不能 100% 定性为表锁，需交叉验证。关键看 SHOW PROCESSLIST 中状态字段和 INFORMATION_SCHEMA.TABLES 的引擎信息。
实操建议：
- 执行
SHOW PROCESSLIST，若看到多个线程卡在Locked状态，且Info列显示对同一张表的SELECT或INSERT，基本可断定是 MyISAM 表锁竞争 - 查表引擎：
SELECT ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';，确认返回MyISAM - 检查是否有长时间运行的写操作：比如未提交的
ALTER TABLE（MyISAM 下会锁全表）、或大事务中的INSERT ... SELECT，这类操作会让后续所有请求排队
为什么 key_buffer_size 设置不当会加剧表锁感知
MyISAM 依赖 key_buffer_size 缓存索引块，但不缓存数据（数据直读磁盘）。如果该值过小，索引页频繁换入换出，导致每次查询实际 I/O 增加，表面看像锁等待，实则是磁盘争抢。用户常误判为“锁瓶颈”，其实优化缓冲区就能缓解。
实操建议：
- 监控
Key_reads / Key_read_requests比率（通过SHOW STATUS LIKE 'Key%'），若 > 0.01，说明索引缓存命中率差，应增大key_buffer_size - 不要盲目设为物理内存 25%，MyISAM 实际有效上限通常在 1–2GB；超过后反而因内存碎片降低效率
-
key_buffer_size和表锁无直接关系，但它影响单次查询执行时间 —— 执行越慢，持有锁的时间就越长，间接放大锁竞争
替换引擎前必须验证的三个点
把 MyISAM 改成 InnoDB 是常见解法，但不是无痛切换。很多线上问题源于迁移后行为差异被忽略。
实操建议：
- 确认应用是否依赖 MyISAM 的
AUTO_INCREMENT行为：MyISAM 在并发插入时允许间隙，InnoDB 严格递增且有间隙锁逻辑，可能引发主键冲突或死锁 - 检查全文索引：MyISAM 的
FULLTEXT索引语法与 InnoDB 不完全兼容，迁移后需重建并测试MATCH ... AGAINST查询结果一致性 - 验证
SELECT COUNT(*)性能变化：MyISAM 快速返回精确行数（内存维护），InnoDB 需扫描或采样，若业务代码依赖该语句做分页总数，可能需加缓存或改用近似计数
表锁问题本身不难定位，难的是区分它是纯粹的并发模型限制，还是被索引缺失、缓冲不足、或长事务掩盖的真实瓶颈。别急着换引擎，先让 SHOW PROFILE 和 PROCESSLIST 对上慢日志里的每一行。
