MyISAM 为什么只支持表级锁？
因为 MyISAM 的设计里没有行级锁所需的元数据结构和并发控制机制。它不维护每行的事务状态、版本号或行锁信息，所有写操作（
INSERT、
UPDATE、
DELETE）都直接对整个表加
WRITE锁，读操作加
READ锁 —— 这是引擎层硬编码的行为，没法通过配置开启行锁。
MyISAM 表锁和 InnoDB 行锁的实际表现差异
在高并发更新场景下，这种差异立刻暴露：
SELECT COUNT(*) FROM myisam_table会阻塞后续所有
INSERT，哪怕只查一行；而 InnoDB 的相同语句通常不锁表（除非用了
SELECT ... FOR UPDATE） 两个连接同时执行
UPDATE myisam_table SET x=1 WHERE id=100和
UPDATE myisam_table SET x=2 WHERE id=200，后者必须等前者释放全表锁；InnoDB 中这两条会各自锁定对应行，互不干扰
REPAIR TABLE或
OPTIMIZE TABLE在 MyISAM 上是独占锁，期间整个表不可读不可写；InnoDB 对应操作（如
ALTER TABLE ... ALGORITHM=INPLACE）多数支持在线 DDL
为什么不能给 MyISAM 加行锁？技术上卡在哪
不是“不想”，是根本没实现的基础：
MyISAM 的索引文件（.MYI）只存 B-tree 结构和指针，不存事务 ID、回滚指针、隐藏列（如
DB_ROW_ID、
DB_TRX_ID） 没有 Undo Log 机制，无法支持 MVCC 或语句级回滚，自然不需要行级锁来协调多版本读写 崩溃恢复靠
.MYD文件校验和
myisamchk，不依赖 WAL 或 Redo Log，也就没有日志驱动的锁管理上下文
mysql> SHOW CREATE TABLE myisam_example\G
*************************** 1. row ***************************
Table: myisam_example
Create Table: CREATE TABLE `myisam_example` (
`id` int NOT NULL,
`data` varchar(100) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4
-- 注意这里：ENGINE=MyISAM，决定了锁粒度上限就是表现在还该用 MyISAM 吗？关键判断点
除非你明确满足以下全部条件，否则不要选：
数据完全静态或极少更新（比如配置表、字典表），且SELECT压力极大 服务器内存极小（ 必须使用全文索引且 MySQL 版本 FULLTEXT） 能接受备份时停写、修复时锁表、主从延迟突增等运维代价
现实中，连
ARCHIVE引擎在只追加场景下都比 MyISAM 更安全——真正绕不开 MyISAM 的情况，现在基本只剩遗留系统迁移前的兼容性锚点。
