分享改进 高性能通用分表归档存储过程测试结果更新

因高层突然变卦 要以存储过程来完成订单的拆分归档工作 所以虫子的同步工具先暂时搁置一段时间。

详细设计参考原理篇

更新一下测试结果 旧的测试结果放在下面 前一篇关于限制性开源的文章先删除 因为是企业在用项目 所以不开放性公布源码了 有需要交流的同学可以单独联系虫子

---

更新内容

　　解决了一些bug，例如以前按一级表、二级表、三级表...的顺序删除，结果导致一级表删除后，二级表的数据读取错误。

　　优化了过程安全，在3个阶段进行临时表和游标资源的check。降低预料外异常对程序的影响。

　　改变删除的设计。

　　总的来说不是从性能上更新，而是从业务角度保证数据的完整性

---

 最新测试结果

　500条

查看原图 ：http://pic002.cnblogs.com/images/2011/87114/2011121412594683.jpg

1000条

查看原图 ：http://pic002.cnblogs.com/images/2011/87114/2011121413012846.jpg

3000条

查看原图 ：http://pic002.cnblogs.com/images/2011/87114/2011121413020332.jpg

5000条

 查看原图 ：http://pic002.cnblogs.com/images/2011/87114/2011121413024434.jpg

---

旧的测试结果

先晒下性能 测试环境 总共33张表 数据量如下

 

归档表初始化

先看批次500条的性能

看看运行时间

2.342秒 ！！！！！

看看我们插入了的数据是否准确

OK源表的数据是500 或许大家对这组数据不以为然 但是你要明白 在33张特大表中进行的操作 并且之间层级关联 各种安全 容错处理

再清除一下 试试5000条

70秒 有木有 有木有 比预想的性能要差一些 因为5000条所涵盖的事务太大

数据还是很完美

总的来说 这样的性能对于这样的应用场景 应该没有多少老大会不满意了

---

 先简单阐述一下概要 详细查看 原理篇

源表：一般是指同步 归档等的主表 demo中以订单头表为例

一级表：以源表为关联表的数据表

二级表：以一级表为关联表的数据表

...

异常表：容错处理 用来存放异常数据 如果当期批次出错 则将本次批次源表关联键信息入库 下一批次则过滤这些数据再执行

减少IO的操作次数 用游标循环源表来关联一级表 二级表等 是很错误的方案

理清层级关系 源表过滤数据副本化 如果一级表关联的操作次数比较多那么可以模仿源表操作 以临时表取代物理表 如果表关联的操作次数不多可以直接生成数据过滤池