答案：MySQL锁等待问题可通过系统视图和日志分析快速定位，首先查询INNODB_TRX和INNODB_LOCK_WAITS获取事务状态与阻塞关系，结合performance_schema.data_lock_waits查看锁等待详情，启用慢查询日志排查执行时间长或未提交事务，通过模拟场景验证锁行为，最终借助监控工具实现持续观察与告警。
MySQL锁等待问题会直接影响数据库的并发性能和响应速度，导致请求堆积、事务超时甚至服务不可用。要快速定位并解决这类问题，需结合系统视图、日志信息和实际SQL行为进行分析。以下是实用的诊断方法和检测技巧。
查看当前锁等待状态
MySQL提供了performance_schema和information_schema中的表来帮助查看锁相关信息，特别是INNODB_TRX、INNODB_LOCKS（MySQL 5.7及以下）、INNODB_LOCK_WAITS等。
-
查询正在运行的事务：使用
SELECT * FROM information_schema.INNODB_TRX;可看到当前所有InnoDB事务，重点关注trx_state为“RUNNING”但长时间未提交的事务，以及trx_query中执行的SQL。 -
查看锁等待关系：通过
INNODB_LOCK_WAITS可以找出哪个事务在等待哪个事务释放锁。例如：SELECT waiting_trx_id, blocking_trx_id, blocking_pid FROM information_schema.INNODB_LOCK_WAITS;结合INNODB_TRX找到对应的线程ID（trx_mysql_thread_id），便于进一步追踪。
启用并分析Performance Schema
从MySQL 5.7开始，推荐使用performance_schema中的data_locks和data_lock_waits表替代旧的INNODB_LOCKS等表。
- 确认是否开启相关监控：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%wait/synch%'; - 查看当前数据行锁情况：
SELECT * FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'your_db';
- 找出阻塞源：
SELECT * FROM performance_schema.data_lock_waits;
这个表显示了等待锁与持有锁之间的关系，能清晰看出谁在等谁。
检查慢查询与未提交事务
很多锁等待源于长时间运行的事务或未及时提交的操作。
- 开启慢查询日志，分析执行时间长的语句。设置
long_query_time = 1并检查日志文件，查找全表扫描、缺少索引或逻辑复杂的SQL。 - 定期检查是否存在“空闲但未提交”的事务。这类事务可能由应用连接池异常或代码中遗漏
COMMIT/ROLLBACK引起。 - 使用如下语句查找长时间运行的事务：
SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX ORDER BY trx_started;
模拟与复现锁场景
在测试环境可通过手动操作复现锁等待，验证诊断逻辑。
- 会话A执行：
BEGIN; UPDATE users SET name = 'test' WHERE id = 1; - 会话B执行相同更新，将被阻塞。此时查看
INNODB_TRX和data_lock_waits，观察等待关系。 - 结束A的事务后，B自动继续执行，验证锁释放机制。
基本上就这些核心手段。关键是建立监控习惯，及时发现长时间事务和锁争用。生产环境中建议结合如Prometheus + Grafana或Percona Toolkit工具自动化采集和告警，避免问题扩大。
