一、表碎片的产生

对于mysql表数据，当你delete掉很多数据时，这些数据占用的磁盘空间可能并不会立刻被回收；比如一张表有10G的数据，delete掉1G数据后，再查看表ibd文件会发现文件大小可能还是10G；如果这个表有insert操作的话，那么mysql就会优先考虑能不能将新数据存储到空白空间上，容易出现这样的情况：某个空白空间的大小是2MB，新插入一条数据大小是1.5MB并存储到该空白空间上，这时就会产生更小的空白空间，而这种更小的空白空间更难被利用，如果像这种碎片非常多，就会比较浪费资源而且降低表磁盘I/O性能。
对于频繁地update操作，也很容易产生碎片问题。比如对于可变长字段，如varchar、text、blob等字段，如果update操作将数据大小改小，那么也会产生碎片问题。
mysql目前比较常用的引擎是innodb和myisam，这两种引擎下都有可能产生碎片，碎片的产生和消除都是随机的，而碎片越多会给查询扫描工作带来越大的影响。

二、查看表碎片的方式

1、data_length+index_length与ibd文件大小的比较

mysql5.5默认是共享表空间，从5.6开始默认是独立表空间，每张表有自己的文件空间。查看方式就是看数据文件大小和表数据量大小的差异：可以先在数据库中通过系统表information_schema.tables或者“show table status like ‘tb’ ”语句计算出data_length+index_length的值，再到操作系统上查看对应表的ibd文件(或者myd、myi文件)的物理大小。如果ibd文件比data_length+index_length值大很多，说明表存在碎片。
例如查看test库下student表的碎片空间情况：

1
2
3
4
5
6
7
8
9
10
11

mysql> select table_name,(data_length+index_length)/1024/1024 length,engine,data_free    
    -> from information_schema.tables    
    -> where table_name='student';
+------------+-------------+--------+-----------+
| table_name | length      | engine | data_free |
+------------+-------------+--------+-----------+
| student    | 72.14062500 | InnoDB |   4194304 |
+------------+-------------+--------+-----------+
1 row in set (0.01 sec)
[root@cos7-jiang test]# ll -h student.ibd
-rw-rw----. 1 mysql mysql 76M Dec 12 13:53 student.ibd

根据系统表计算出student表数据为72MB，查看ibd文件大小为76MB，碎片空间大概有4MB左右，不算太多。

2、通过系统表tables的data_free字段看表碎片

mysql的系统表information_schema.tables中记录着每张表的数据、索引大小，行数等重要信息，主要字段信息如下：
table_schema：表所在数据库名
table_name：表名
engine：表的存储引擎
tables_rows：表数据行数
data_length：数据长度，即表数据大小，单位字节
index_length：索引长度，即表索引大小，单位字节
data_free：已分配但未使用的空间大小，单位字节，可以认为是碎片空间
通过data_free字段可以查出数据库中有哪些表产生了碎片，data_length+index_length值就是表数据量总大小(拿这个求和值与表数据文件大小比较，得到的差值往往与data_free值不一样，不知道为什么)。
可以用下面的SQL来统计数据库中有哪些表产生了碎片空间：

1
2
3
4
5
6
7
8
9

mysql> select table_name,table_schema,engine,table_rows,data_length+index_length length,data_free    
    -> from information_schema.tables    
    -> where data_free !=0
    -> and table_schema not in('information_schema','mysql','performance_schema');
+------------+--------------+--------+------------+----------+----------+
| table_name | table_schema | engine | table_rows | length   | data_free|
+------------+--------------+--------+------------+----------+----------+
| student    | test         | InnoDB |    1075752 | 75644928 |   4194304|
+------------+--------------+--------+------------+----------+----------+

data_free值可以反映出表的碎片空间大小。上面student表data_free显示4M，与上一个方式计算出的碎片大小近似吻合。

三、清理表碎片

一般通过optimize命令清理碎片，不过optimize命令对共享表空间不起作用。
对于mysql5.6，如果执行optimize table tb_name优化innodb表可能会报如下信息：

1
2
3
4
5
6
7

mysql> optimize table jiang;
+------------+----------+----------+-------------------------------------------------------------------+
| Table      | Op       | Msg_type | Msg_text                                                          |
+------------+----------+----------+-------------------------------------------------------------------+
| test.jiang | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.jiang | optimize | status   | OK                                                                |
+------------+----------+----------+-------------------------------------------------------------------+

对于innodb表的优化，可以用alter table tb_name engine=innodb的形式优化，对于myisam表的优化可以直接使用optimize。

四、optimize操作介绍

mysql5.6的官方文档在13.7.2.4小节对optimize操作有详细的介绍。optimize table命令的作用是重新组织表数据和关联索引数据的物理存储，以减小存储空间并提高访问表时的I/O效率；命令主要作用于innodb、myisam和archive引擎表，而命令对表所做的实际更改取决于该表使用的存储引擎。
·innodb引擎下的optimize操作
对于innodb表，optimize table操作实际映射为alter table … force操作，当对innodb表执行optimize操作时可能会出现下面的提示信息：

1
2
3
4
5
6
7

mysql> optimize table jiang;
+------------+----------+----------+-------------------------------------------------------------------+
| Table      | Op       | Msg_type | Msg_text                                                          |
+------------+----------+----------+-------------------------------------------------------------------+
| test.jiang | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.jiang | optimize | status   | OK                                                                |
+------------+----------+----------+-------------------------------------------------------------------+

这实际上已经对表做了优化，第一步是提示optimize操作不适用该类型表，第二步是映射为alter table操作执行并成功。
在mysql5.6.17之前，optimize操作没有使用online DDL，因此整个操作期间会锁表，表上不允许有DML操作；
从mysql5.6.17开始，对于常规的和分区的innodb表，optimize操作使用online DDL，这样只会在操作的准备阶段和提交阶段锁住DML操作，大大提高了并发性。

说明：
1、对于写比较频繁的表，容易产生碎片问题，但也不用经常进行清理，一般每周或者每月一次就可以了；
2、OPTIMIZE TABLE只对MyISAM，BDB和InnoDB表起作用，尤其是MyISAM表的作用最为明显。此外，并不是所有表都需要进行碎片整理，一般只需要对包含可变长度的文本数据类型的表进行整理即可。

12月工作目标

1. 西安国际呼叫中心–张琳

2. 一个专病（统计）

3. 专科随访高级筛选–金翔

4. 迭代内容（南京鼓楼、吉大一、邵逸夫、华西二院）–毛子杰、吴森

5. 微信模版（医院通知模版不可用，寻找替代模版）–徐贤

6. 动态满意度优化（每一次保存表单内容，数据库占硬盘空间太大）–高翔

7. 病程管理–陈孝伟

8. 体检预约–陈孝伟

9. 数据库ibd文件瘦身–林剑

10. 现场问题–高翔

11. 自动发送线程控制优化

12. 自动筛选流程优化

12月验收项目：邵逸夫（GPS、生物样本库）、舟山妇保、鄞州人民、厦门心血管、云大一、南阳二院、 南京鼓楼、吉大一、东莞八院、台州第一

12.2

1. 腹透、糖尿病、高尿酸关注指标，随访路径学习了解

2. 月会

12.3

1. 迭代内容确定

2. b21宣讲

3. 余杭第一病例复印一个患者多个微信问题

12.4

1. 专科随访高级筛选技术方案讨论

2. 余杭第一补丁包发布

3. 台州中心发送到达率（注册过APP后卸载，没有关注公众号，患者收不到。解决方案：根据上一次发送后患者是否登陆app，返回随访推送成功状态）

4. 12月项目部需求确认

5. Mysql表碎片优化

12.5

1. 查看重庆医药接口文档，整理对接技术方案

2. 下城区门诊自助数据表单自动填充（刷蓝牛二维码改为刷医保卡）

3. 厦门心血管专科筛选（慢病）代码同步（已处理）

4. 吉大一表单内容异常（个性化定制功能自定义逻辑验证未控制权限、云端处理表单json也有问题，晚上更新）

5. 医院通知模版替换（医院提醒OPENTM207960707）

12.6

1. 自动筛选原流程梳理

   • 每天5,12,18,23 触发筛选定时器

   • 新建、编辑触发筛选（第一次执行）

   • 禁用/开启自动筛选，触发自动筛选

   • 手术、药品等条件每次筛选都调用一次接口

2. 原自动筛选问题：

   • 各模块的都有各自的筛选定时器

   • 每一个个计划筛选都调用接口取数据

   • 过滤条件先后顺序可优化

3. 2.3.1b22宣讲

4. 高级筛选宣讲

12.7

1. 自动筛选优化方案设计

   • 抽样筛选

   • 第一次执行

12.9

1. 自动筛选优化方案设计

   • 普通筛选采用Event事件通知

   • 抽样筛选单独处理

2. 出差（厦门心血管医院接口方案沟通）

12.10

1. 厦门心血管医院接口方案沟通

   • 门诊同步中间库

   • 住院视图

   • 检验接口cdr并发查结果（平台先看是否能优化，不行开视图同步到本地）

2. 药品宣教需求调研

   • 按钮嵌入药房系统（点开弹出出院带药列表，默认勾选所有药物，点击生成宣教，可打印，可手动发送）

   • 随访要展示发送记录，已读状态，可再次发送

12.11

1. 新附一统计问题查看（现象重现，原因暂未找到）

2. 自动筛选优化方案（抽样筛选）

12.12

1. 表单自动填充（自定义配置）方案设计

2. 省妇保随访CPU占用高（宣教自动筛选，诊疗情况导致）

3. 2.3.1b23宣讲

4. 宁波第一短信模版修改

12.13

1. 汕大一 5860736B 根据出院转归情况筛选

12.16

1. 自动筛选优化方案评审（暂不大概，先优化）

   • 编辑后重头筛选修改（留隐藏入口）

   • 筛选时间范围》1天，拆成一天一天调用接口获取数据

2. 满意度自动发送优化（原有逻辑梳理）

12.17

1. 满意度自动发送优化
   • 每个计划的线程可以去掉，发送的时候多线程即可
2. 表单自动填充功能讨论

12.18

1. 随访、宣教自动发送优化

2. 广妇儿317护宣教内网查看不了（nginx配置问题）

3. 嘉兴二院广妇儿临床路径定时器在执行（判断代码有问题）

4. 表单自动填充宣讲

12.19

1. 表单自动填充计划

2. 满意度分类上传云端（已完成）

3. 鄞州人民医院APP预约挂号科室问题（接口需要处理）

4. 二维码表单信息录入问题排查

12.20

1. SPSS使用学习（工具基本使用、T检验）

2. 浙江医院投标

3. 宁波第一短信模版修改

4. 成都锦欣集团医患互动统计

5. 专科统计宣讲（1型糖尿病/小儿哮喘）

12.21

1. 统计相关知识学习

2. SPSS使用学习

12.23

1. mongodb关联查询（$lookup 、$match）

2. 吉大一随访嵌入页面bug（分页参数传错）

3. 迭代、专科、表单自动填充任务跟踪，表单自动填充实现细节讨论

4. 数据分析方法论学习

12.24

1. b24提测，b25宣讲

2. 广妇儿知识库嵌入随访页面问题（xp系统支持chrome版本太老，推荐更新系统）

3. rap2性能问题（服务器资源紧张，jenkins打包占用大量资源；数据库在阿里云上，数据网络传输慢）迁移数据库到内网环境

12.25

1. 新附一需求讨论

   • 二维码满意度统计

   • 宣教统计（在院宣教统计）

2- 广妇儿317护宣教查看问题处理（历史数据问题）

3- 满意度发送优化

12.26

1. 表单失败重发、凌晨发送问题讨论，出解决方案

2. 凌晨发送问题处理方案（改配置文件、迭代升级版本）

3. 云端驾驶舱上传时间调整为22点触发，程序创建触发器

12.27

1. 国科大人流患者管理随访全息档案兼容

2. 广妇儿宣教记录查看404（第三方宣教）

3. 江苏省人民CPU暴增问题处理（门诊记录同步阻塞）

12.28

1. 随访发送优化

2. 发送保存url评估

12.30

1. 江苏省人民医院科研随访表单保存数据，历史记录无数据问题

2. 国科大编辑计划报错（去查了所有患者导致内存溢出）

3. 2.3.1b26宣讲

4. 随访小结、健康评估报告宣讲

5. 发送保存url评估

12.31

1. 年前计划制定

2. 随访发送优化

3. 2.3.1b25提测–1.2

4. 2.3.1b26提测–1.6

5. 随访小结、健康评估报告提测–1.13

事项

• 迭代（毛子杰、吴森）– 12.24提测

• 专科统计（高翔、张琳）

• 表单自动填充（金翔、费嘉良、徐贤）

• 体检预约（陈孝伟、汪佳美）

日间手术介绍

日间手术是临床诊断明确的患者在24小时内完成计划性住院、手术、术后短暂观察并出院的一种手术模式。

日间手术的产生及发展完全出于改善患者诊疗服务的目的。它在缓解病人住院难、缩短患者住院天数、降低医疗费用、节约医保基金、加快医院病床周转率等方面具有显著的积极作用。据文献资料查找，通过日间手术的开展，同种手术患者的平均住院费用可降低1040%，平均住院天数可降低25天。

流程

功能模块设计

患者管理

对要做日间手术的患者进行管理。

• 添加日间手术患者（从门诊记录根据科室、诊断添加患者）。操作（入组、暂不入组、不可入组），入组需要选择手术方式（宫腔镜手术、腹腔镜手术、其他）

• 手术患者列表可根据门诊号、姓名、门诊诊断、术前评估状态（待评估、评估中、评估完成、强制评估完成）、预约状态（待预约、已预约、取消预约、爽约）、入组时间进行搜索

• 列表可以点击病程管理进入病程管理页面，可以查看患者当前所处阶段，任务执行情况。

麻醉会诊管理

麻醉科医生对日间手术患者进行麻醉评估，可查看已评估患者的评估说明。

排班管理

维护日间手术排班。

• 可维护本周至之后3周的排班信息（包含本周）。

• 设置排班模版。

• 根据模版生成一年排班。

• 推送排班信息

• 默认显示下一周排班。

排班总览

查看排班信息。

• 默认显示当前周排班。

预约管理

对日间手术预约情况进行管理。

• 待预约。对未预约患者预约手术时间。

• 已预约。查看已预约患者信息，群发术前宣教，导出患者数据。

• 已取消。查看取消预约患者信息及取消原因，删除预约记录。

• 已爽约。查看爽约患者信息及爽约原因，删除预约记录。

医生管理

维护日间手术的医生、手术室信息。

医生手术管理

给已预约患者分配手术医生、手术室、及手术顺序号。

医生手术总览

查看医生手术排台情况。

疾病路径管理

维护日间手术随访路径。

• 术前任务根据手术方式（宫腔镜、腹腔镜、其他）匹配路径。

• 术后任务根据手术名称匹配路径。

任务管理

病程管理任务列表。可根据任务状态（已完成、未完成）、发送状态（未发送、已发送、已回复、异常）、计划发送时间等搜索。

• 手动发送

• 删除任务

• AI推送

• 随访

E-R图

数据库设计

问题

t_repository_form_answer数据量近亿级，需要增加字段，新建临时表t_repository_form_answer_tmp（增加字段），copy数据到临时表，删除原表，修改临时表名。

由于数据量过大，导致copy数据耗时太久，回滚版本未及时kill掉数据库进程，1天后发现copy进程还在，kill掉进程出现killed死锁。

1

SELECT * FROM information_schema.INNODB_TRX

查询trx_rows_modified数据量高达6000万，mysql在执行事务回滚操作，但是数据减小速度比较慢，同时表锁住导致表单提交答案失败。