关于医院数据库锁表优化浅谈

南京市口腔医院 江苏 南京 210018

1 研究背景

1.1 业务背景

鉴于我院的数据库在2020年4月12日及4月13日两天接连锁表，且锁表时间段均为非业务高峰期。我们对数据库环境进行了为期一个月的监控以及相关优化。

1.2 技术背景

众所周知，数据库健康状态最为明显的体现就在于I/O读写的速度快慢，索引所使用的磁盘空间越大则sql语句运行的就更为缓慢，当运行缓慢的sql产生了阻塞及互相等待的时候就会造成数据库的锁表现象，锁表主要分为以下类型：

（1）共享锁。S锁，也叫读锁，用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源[1]。

（2）排他锁。X锁，也叫写锁，表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。

（3）更新锁。U锁，在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。

2 问题分析

锁表当日对数据库情况进行分析，优先排除了HIS数据库服务器压力过大原因导致的锁表。同时分析，HIS数据库在相当长的一段时间内并未发生锁表问题，怀疑是由于业务科室偶发性的跨大时间段的数据查询，引起数据库超负荷，导致数据库锁表。问题发生时的紧急处理方式是杀掉引起锁表进程。除此之外并没有更好的方式。为了预防和解决此类现象我们对该数据库进行了分析和处理[2]。

3 查找原因

3.1 原因分析以及针对性处理

通过实时数据查找，发现mz_visit_tale，mz_detail_charge，gh_detail_charge等业务主表的数据量过大，最大数据量达到3000w。……