InnoDB行锁依赖索引，无索引时退化为全表扫描加锁，效果近似表锁；MyISAM所有DML均隐式加表锁，无事务、不支持行锁或间隙锁。
InnoDB 支持行锁，MyISAM 只能表锁——这不是“能不能选”的问题，而是引擎决定的硬限制；Java 或应用层发什么 SQL 都改不了这个事实。
InnoDB 行锁只在走索引时生效
行锁不是锁“数据行”，而是锁“索引记录”。只要 WHERE 条件没命中索引（比如查 phone 字段但该字段没建索引），InnoDB 就会全表扫描，对扫到的每一行都加锁，效果等同于表锁。
- 验证方式：执行
EXPLAIN SELECT * FROM user WHERE phone = '138' FOR UPDATE，看key列是否为NULL；若为NULL，说明没走索引，锁已退化 - 高频更新字段（如
status、order_no）必须建索引，否则一写就堵住整张表 - 二级索引查询会锁两次：先锁二级索引条目，再锁对应主键记录——别以为“只查了索引”就安全
MyISAM 所有 DML 操作都隐式加表锁
MyISAM 没事务、不支持行锁，UPDATE、DELETE、INSERT 语句执行时自动加表级写锁，语句结束即释放。它没有“锁住某行后等待提交”这回事。
- 显式加锁用
LOCK TABLES t1 WRITE，必须配对UNLOCK TABLES，否则其他会话对t1的任何读写都会卡在Waiting for table level lock - 长事务不存在，但长 SQL 存在——比如
UPDATE t1 SET x=1 WHERE y LIKE '%abc'（无索引 + 全表扫描），锁表时间等于扫描耗时 -
SELECT加读锁（LOCK TABLES t1 READ）允许并发读，但会阻塞所有写操作，包括INSERT
RR 隔离级别下 InnoDB 有间隙锁，MyISAM 完全没有
可重复读（RR）下，SELECT ... FOR UPDATE 不仅锁命中的行，还锁住前后间隙（Gap Lock），防止幻读。MyISAM 根本不支持事务隔离级别，自然也没有间隙锁、临键锁这些概念。
- 间隙锁只在 RR 下生效，读已提交（RC）会关闭它——所以 RC 下范围查询不会锁间隙，但可能多读出新插入的行
- 间隙锁容易引发死锁，尤其当两个事务用不同顺序更新范围数据时（如事务 A 查
id BETWEEN 10 AND 20，事务 B 查id BETWEEN 15 AND 25） - MyISAM 的“一致性”靠应用层保证，数据库本身不做任何并发控制，适合报表类只读场景，不适合订单、库存等业务
真正容易被忽略的是：InnoDB 的“行锁”能力不是默认开启的魔法开关，它极度依赖 SQL 写法和索引设计；而 MyISAM 的表锁是无条件生效的，哪怕你只改一行，也得接受整张表停摆的事实。
