Linux系统下运行的数据库服务，尤其是MySQL、PostgreSQL这类关系型数据库，在并发事务处理过程中很容易出现死锁问题。死锁指的是两个或多个事务互相持有对方需要的锁资源，同时都在等待对方释放锁，导致所有相关事务都无法继续执行的情况，会直接影响业务的正常访问。
死锁的常见触发原因
要解决问题首先需要明确死锁的产生条件，通常Linux系统下的数据库死锁由以下原因导致：
- 事务执行顺序不一致，多个事务以不同的顺序申请相同资源的锁，形成循环等待
- 事务持有锁的时间过长，比如事务中包含大量非数据库操作，导致锁占用时间超出合理范围
- SQL语句没有合理使用索引，导致锁升级，从行锁变成表锁，增加锁冲突的概率
- 事务隔离级别设置过高，比如使用可重复读级别时，间隙锁的范围过大，容易引发死锁
排查Linux系统下的数据库死锁
查看MySQL死锁日志
如果是MySQL数据库，默认会记录死锁相关的日志，我们可以通过以下方式查看：
首先登录MySQL客户端，执行如下命令查看最近一次的死锁信息：
SHOW ENGINE INNODB STATUSG
在输出的结果中找到LATEST DETECTED DEADLOCK部分，里面会记录死锁发生的时间、涉及的事务ID、每个事务持有的锁和等待的锁、最终被回滚的事务等信息，我们可以根据这些内容分析死锁的触发逻辑。
查看PostgreSQL死锁日志
PostgreSQL的死锁日志默认不会自动记录，需要先修改配置文件postgresql.conf，设置log_min_messages为log级别，同时开启deadlock_timeout参数，之后重启服务，死锁发生时就会在日志文件中记录相关信息，日志路径通常在/var/log/postgresql/目录下。
解决死锁的具体方法
临时处理正在发生的死锁
如果死锁正在发生，我们需要先终止阻塞的事务，释放锁资源：
MySQL中可以通过如下语句查看当前运行的事务和锁等待情况：
-- 查看当前锁等待信息 SELECT * FROM information_schema.INNODB_LOCK_WAITS; -- 查看当前运行的事务 SELECT * FROM information_schema.INNODB_TRX;
找到阻塞时间最长的事务ID，执行KILL命令终止该事务：
KILL 事务对应的线程ID;
PostgreSQL中可以通过pg_stat_activity视图查看当前活跃连接，找到阻塞的事务进程ID，执行如下命令终止：
SELECT pg_terminate_backend(进程ID);
调整数据库参数减少死锁概率
合理调整数据库参数可以从系统层面降低死锁发生的概率：
- 设置合理的锁等待超时时间，避免事务长时间等待锁资源，MySQL中可以通过innodb_lock_wait_timeout参数调整，默认是50秒，可以根据业务情况适当缩短，比如设置为30秒
- 调整事务隔离级别，如果业务允许，可以将隔离级别从可重复读调整为读已提交，减少间隙锁的使用范围，降低死锁概率
- 开启死锁检测机制，MySQL的InnoDB引擎默认开启innodb_deadlock_detect参数，会自动检测死锁并回滚代价最小的事务，不需要手动关闭
优化业务代码避免死锁
除了数据库层面的调整，业务代码的优化是避免死锁的根本方法：
- 所有事务中的SQL操作按照相同的顺序访问表和行，避免交叉申请锁资源
- 尽量缩短事务的执行时间，把非数据库操作比如接口调用、文件读写放到事务外面，减少锁的持有时间
- 给查询语句添加合适的索引，避免全表扫描导致的锁升级，比如给where条件中的字段添加索引
- 避免在一个事务中同时操作过多的数据行，拆分大事务为多个小事务执行
死锁预防的最佳实践
日常开发中可以遵循以下实践预防死锁：
- 上线前对核心事务的SQL进行压测，模拟高并发场景，观察是否会出现死锁
- 定期查看数据库的死锁日志，统计高频死锁的场景，针对性优化对应的SQL和事务逻辑
- 对于并发度很高的热点数据，可以考虑使用乐观锁代替悲观锁，通过版本号机制避免锁冲突
- 如果业务允许，对读多写少的场景使用读写分离架构，减少写事务之间的锁竞争
总结
Linux系统下的数据库死锁问题需要从排查、临时处理、参数调整、代码优化多个层面共同解决。遇到死锁时先通过数据库日志定位成因，再针对性调整事务逻辑和数据库参数，同时做好日常的预防工作，就能大幅降低死锁的发生概率，保障数据库服务的稳定运行。