mysql在InnoDB中会用表锁而非行锁的情况是：当查询无法使用索引或全表扫描时，InnoDB会对所有扫描记录加锁并配合间隙锁，实际效果接近表锁；常见场景包括无索引/索引失效、LIKE ‘%abc’、ALTER table、显式LOCK TABLES。
什么时候 MySQL 会用表锁而不是行锁
MySQL 默认在 InnoDB 引擎下走行锁，但一旦查询无法使用索引、或用了 select ... for UPDATE / UPDATE 时走了全表扫描，InnoDB 就会升级为表锁（更准确地说：对所有扫描过的索引记录加锁，再配合间隙锁，实际效果接近锁整张表）。
常见触发场景包括：
-
WHERE条件字段没建索引，或索引失效（比如对索引列做函数操作：WHERE YEAR(create_time) = 2024） - 使用
LIKE '%abc'导致索引无法命中 - 执行
ALTER TABLE（尤其是非原子 DDL，在老版本 MySQL 中会锁表） - 显式使用
LOCK TABLES ... WRITE（MyISAM 默认行为，InnoDB 不推荐）
InnoDB 行锁的三种类型怎么影响并发
InnoDB 的行锁不是“锁某一行”，而是基于索引记录的锁，分三类：
-
Record Lock：锁住索引中某条具体记录（如主键值为100的行） -
Gap Lock：锁住索引记录之间的“间隙”，防止幻读（例如锁定(10, 20)这个范围，不允许插入15） -
Next-Key Lock：Record Lock + Gap Lock的组合，是 InnoDB 默认的可重复读（REPEATABLE READ）隔离级别下的行锁行为
关键点：
- 没有索引的表？InnoDB 会为隐式聚簇索引（即主键）加锁；若没定义主键，它会自建一个隐藏的
row_id索引——这时锁行为难以预测，且容易锁多 - 唯一索引等值查询（
WHERE id = 123），只加Record Lock；范围查询（WHERE id > 100）则必然带Gap Lock - 想禁用间隙锁？可临时设
SET session transaction_isolation = 'READ-COMMITTED'，但需同步评估幻读风险
如何确认当前 SQL 到底锁了什么
不能靠猜。得用 InnoDB 的信息视图定位真实锁状态：
- 查正在运行的阻塞事务：
SELECT * FROM information_schema.INNODB_TRX; - 查锁等待关系：
SELECT * FROM information_schema.INNODB_LOCK_WaiTS; - 查具体锁信息（记录锁在哪、锁类型、事务 ID）：
SELECT * FROM information_schema.INNODB_LOCKS;（注意：8.0+ 已移除此视图，改用
performance_schema.data_locks） - 快速看谁卡住了你：
SELECT BLOCKING_TRX_ID, BLOCKED_TRX_ID FROM performance_schema.data_lock_waits;
特别提醒：SHOW ENGINE INNODB STATUSG 输出里 TRANSACTIONS 部分有最实时的锁等待堆栈，但只保留最近一次死锁信息，且输出易被截断。
表锁与行锁的优化关键其实是索引和事务粒度
真正决定锁范围的，从来不是“选表锁还是行锁”，而是“SQL 走不走得上索引”和“事务包多大”。优化方向很实在：
- 所有
WHERE、JOIN、ORDER BY字段必须有合适索引；用EXPLAIN确认type是ref/range，而非ALL或index - 避免长事务：事务开启后不做任何操作却迟迟不提交，会让锁一直挂着；尤其警惕 ORM 框架里隐式开启又忘记
commit的事务 - 写操作尽量走主键或唯一索引更新，避免
UPDATE ... WHERE non_unique_col = ?触发范围锁扩散 - 高并发更新同一行？考虑用应用层重试 + 乐观锁（如
version字段）替代悲观锁，减少锁冲突
最常被忽略的一点：autocommit=1 是默认，但某些客户端或框架会关掉它；一旦关了，每个语句都成独立事务，看似没写 BEGIN，实则每条 UPDATE 都在持锁直到下次 COMMIT —— 这种隐式锁行为，比表锁还难排查。