mysql执行sql时是否加锁取决于语句类型和隔离级别；select需带for update或lock in share mode才加锁，update/delete是否命中索引决定行锁或表锁，repeatable read下用临键锁防幻读，read committed仅用记录锁。
MySQL执行SQL时会不会加锁？取决于语句类型和隔离级别
会加锁，但不是所有SQL都加锁，也不是所有场景都加同一类锁。核心判断依据是：SELECT是否带FOR UPDATE或LOCK IN SHARE MODE、UPDATE/DELETE是否命中索引、当前事务隔离级别（尤其是READ COMMITTED和REPEATABLE READ）。
哪些SQL会触发行级锁？重点看WHERE条件是否走索引
MySQL的InnoDB引擎只在能通过索引精确定位记录时才加行锁；否则会升级为表锁或锁住索引范围（间隙锁）。常见情况如下：
-
UPDATE t SET x=1 WHERE id = 100：如果id是主键或唯一索引，只锁这一行 -
UPDATE t SET x=1 WHERE name = 'alice'：如果name无索引，可能锁全表；有普通索引则锁匹配的索引项+对应主键行 -
SELECT * FROM t WHERE id > 50 FOR UPDATE：在REPEATABLE READ下会加临键锁（next-key lock），即行锁 + 间隙锁，防止幻读 -
INSERT INTO t VALUES (101, 'bob')：插入前会检查插入位置的间隙是否被锁定，可能触发插入意向锁（insert intention lock）等待
锁类型和兼容性怎么影响并发？别只盯着“行锁”二字
实际执行中，InnoDB常组合使用多种锁：记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）、插入意向锁（Insert Intention Lock）。它们之间有明确的兼容矩阵，比如：
- 两个事务对同一行加
SELECT ... FOR UPDATE：第二个会被阻塞（记录锁互斥） - 事务A锁了
id=5，事务B执行INSERT INTO t VALUES (6, 'x')：若A持有(5,10)的间隙锁，B会等插入意向锁 -
SELECT ... LOCK IN SHARE MODE与SELECT ... FOR UPDATE不兼容，但多个S锁之间兼容
特别注意：READ COMMITTED隔离级别下，InnoDB只加记录锁，不加间隙锁（除外键检查和唯一约束检查），因此幻读可能发生，但锁冲突概率降低。
如何观察正在发生的锁？别只靠猜，用系统表查真实状态
直接查information_schema里的锁视图最可靠，但需有PROCESS权限：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.INNODB_LOCK_WAITS w INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;
再配合：
-
SELECT * FROM information_schema.INNODB_TRX看当前活跃事务 -
SELECT * FROM information_schema.INNODB_LOCKS（MySQL 8.0.1之前）或performance_schema.data_locks（8.0.1+）看具体锁对象 - 执行
SHOW ENGINE INNODB STATUS\G获取最近的死锁详情（含事务堆栈和锁模式）
间隙锁和临键锁不会单独出现在INNODB_LOCKS里，而是体现在data_locks的LOCK_MODE字段（如RECORD, GAP, RECORD_GAP）。
真正容易被忽略的是：即使SQL看起来“只读”，只要加了FOR UPDATE或LOCK IN SHARE MODE，就参与锁竞争；而看似写操作的UPDATE ... LIMIT 1，若没走索引，可能锁住扫描到的所有行——这比想象中影响更大。
