在 MySQL 中，锁等待是影响并发性能的常见问题。当多个事务竞争同一资源时，后到的事务需要等待前一个事务释放锁，这会导致响应变慢甚至死锁。要提升并发效率，关键在于识别锁等待的原因并针对性优化。以下是几个核心步骤和方法。
查看当前锁等待状态
MySQL 提供了 information_schema 中的表来监控锁信息，尤其是 INNODB_TRX、INNODB_LOCKS 和 INNODB_LOCK_WAITS（注意：MySQL 8.0 已废弃 INNODB_LOCKS 和 INNODB_LOCK_WAITS，改用 performance_schema）。
在 MySQL 5.7 及以下版本中，可以执行：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
在 MySQL 8.0+，使用 performance_schema：
SELECT * FROM performance_schema.data_lock_waits;
通过这些查询，你能看到哪些事务在等待、持有锁的是哪个事务、等待的锁类型和涉及的行或表。
分析事务行为与索引使用
锁等待往往源于长事务或全表扫描导致的锁范围扩大。重点检查以下几点：
确认事务是否及时提交，避免长时间开启事务（如程序中忘记 commit 或 rollback） 查看慢查询日志，找出执行时间长的语句，这类语句容易持有锁更久 确保 WHERE 条件中的字段有合适的索引，否则会升级为表级锁或锁定更多行 UPDATE 或 DELETE 操作若未命中索引，InnoDB 会扫描大量数据并加锁，加剧竞争例如，执行 EXPLAIN 分析 SQL 是否走索引：
EXPLAIN UPDATE users SET status = 1 WHERE email = 'test@example.com';
如果 type 是 ALL，说明做了全表扫描，应为 email 字段添加索引。
减少锁冲突的优化策略
从设计和编码层面降低锁竞争，能显著提升并发能力：
尽量缩短事务长度，只在必要时开启事务，避免在事务中做网络请求或耗时操作 按固定顺序访问多张表，可降低死锁概率 读多写少场景下，使用 READ COMMITTED 隔离级别替代默认的 REPEATABLE READ，减少间隙锁使用 对非核心数据，考虑使用 乐观锁（如版本号控制），避免数据库锁开销 批量更新时分批提交，避免一次锁定过多行启用监控与预警机制
长期运维中建议开启：
performance_schema 中的数据锁监控，持续观察锁等待趋势 设置监控脚本定期检查长时间运行的事务 利用 pt-deadlock-logger（Percona Toolkit 工具）记录死锁详情例如，查出运行超过 30 秒的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 30;
基本上就这些。关键是把锁等待从“看不见的问题”变成可观察、可分析的状态，再结合索引优化和事务控制，就能有效提升并发效率。
