mysql数据库的锁定机制与死锁处理方法

来源：这里教程网时间：2026-02-28 20:40:04 作者：

MySQL 的行级锁和表级锁到底怎么触发

InnoDB 默认用行级锁，但不是所有查询都会真的锁住单行。关键看是否命中索引——

WHERE

条件没走索引时，会升级为表级锁（或间隙锁组合），导致意外阻塞。

常见误判场景：

SELECT ... FOR UPDATE
或
UPDATE
语句中，
WHERE id = ?
走主键索引 → 精确锁单行
WHERE status = 'pending'
且
status
没索引 → 扫描全表，每行加记录锁 + 间隙锁，实际接近表锁效果
INSERT INTO t VALUES (100)
会加插入意向锁，与已有间隙锁冲突时直接等待

如何快速定位正在运行的锁和阻塞源头

别只看

SHOW PROCESSLIST

，它不显示锁信息。真正有用的是 InnoDB 的三张元数据表：

SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

注意：

INNODB_LOCKS

在 MySQL 8.0.1 之后已被移除，改用

performance_schema.data_locks

；如果你用的是 5.7 或早期 8.0，上面三表仍有效。

实用技巧：

查长时间未提交事务：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
结合
sys.innodb_lock_waits
视图（需启用 sys schema）可直接看到谁在等谁、等了多久、SQL 是什么

死锁发生时 MySQL 怎么选 victim 回滚

MySQL 不随机挑，而是按「事务持有锁的代价」决定：回滚修改行数少、undo log 小的那个事务。所以小事务反而更容易被干掉。

典型死锁链路示例：

事务 A：UPDATE accounts SET balance = balance - 100 WHERE id = 1;
事务 B：UPDATE accounts SET balance = balance + 100 WHERE id = 2;
事务 A：UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 等 B 的锁
事务 B：UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 等 A 的锁

此时 MySQL 检测到环形等待，选一个回滚。日志里会记录类似：

Deadlock found when trying to get lock; try restarting transaction

应对要点：

应用层必须捕获这个错误码（
1213
），并重试事务，不能静默失败 避免在事务里做 RPC、文件读写、用户输入等长耗时操作 按固定顺序访问多行（比如总是先更新
id
小的记录），从源头减少环形可能

哪些配置能降低死锁概率但容易被忽略

默认配置对 OLTP 场景不够友好，几个关键项值得检查：

innodb_lock_wait_timeout
：默认 50 秒，线上建议调成 10–30，避免一个慢事务拖垮整条线程池
innodb_deadlock_detect
：默认 ON，高并发下检测开销大；若业务已规避环形访问，可关掉，靠超时机制兜底
transaction_isolation
：避免用
READ-COMMITTED
以外的级别做高频更新——
REPEATABLE-READ
下间隙锁更激进，死锁面更宽

最常被漏掉的一点：没建好联合索引却依赖