答案是监控长事务、缩短执行时间、优化查询路径和合理设置隔离级别。通过performance_schema和information_schema定位长时间持有锁的事务，减少事务内操作并分批处理数据以缩短事务周期，为WHERE条件添加索引、避免隐式类型转换来降低锁范围，根据业务需求选择READ COMMITTED等合适隔离级别，并谨慎使用显式加锁，从而缓解阻塞问题。
在 MySQL 中，事务长时间占用锁会导致阻塞、性能下降甚至死锁。要有效处理这类问题，关键在于识别原因并采取优化措施。
1. 识别长时间持有锁的事务
通过系统视图查看当前锁等待和活跃事务：
-
查看锁等待情况： 使用
SELECT * FROM performance_schema.data_lock_waits;或SHOW ENGINE INNODB STATUS\G查看最近的锁冲突信息。 -
定位长事务： 查询
information_schema.innodb_trx表，关注trx_started和trx_query字段，找出运行时间过长的事务。 -
关联会话信息： 结合
performance_schema.threads和sys.processlist获取客户端 IP 和执行语句。
2. 缩短事务执行时间
事务越长，持有锁的时间就越久。优化方式包括：
- 减少事务内操作数量： 避免在事务中执行大量非数据库操作（如网络请求、复杂计算）。
- 及时提交或回滚： 不要手动开启事务后忘记提交，程序逻辑应确保事务尽快结束。
- 分批处理数据： 大批量更新或删除时，拆分成小批次提交，降低单次事务影响范围。
3. 合理设计索引与查询
缺失索引可能导致全表扫描，进而加锁更多行：
- 为 WHERE 条件字段添加索引： 确保查询能快速定位目标行，减少扫描和锁的范围。
- 避免隐式类型转换： 类型不匹配会使索引失效，导致意外的间隙锁或记录锁增多。
- 使用覆盖索引： 减少回表操作，降低对主键索引的锁定需求。
4. 调整隔离级别与锁策略
根据业务需求选择合适的隔离级别：
- 读已提交（READ COMMITTED）： 可减少间隙锁使用，适用于不需要严格可重复读的场景。
- 避免长事务读： 在高并发写入场景下，尽量不用可重复读（REPEATABLE READ）进行长时间查询。
-
显式加锁控制： 必要时用
SELECT ... FOR UPDATE或LOCK IN SHARE MODE明确锁行为，但要尽快释放。
基本上就这些。核心是：监控长事务、缩短执行时间、优化查询路径、合理设置隔离级别。只要锁持有时间降下来，阻塞问题自然缓解。
