系统迁移遭遇性能挑战

凌晨4点，某银行系统升级现场——

 242 GB核心交易表历经5小时鏖战完成迁移

 长舒一口气的工程师小郑输入一条简单SQL，验证迁移后的系统性能： 

拿起水杯嘬上一口茶水，再细细擦拭泛雾的眼镜，抬头间屏幕显示的SQL返回时间却让小郑瞳孔地震。

足有55秒的艰难应答，这绝不是正常的响应时间。

"这就是我们押注的国产方案？"小郑盯着屏幕上的刺眼数字，握紧的拳头微微发抖。但作为技术人的倔强让他抓起电话："小安，我们需要一场数据库的极限抢救！"

GBASE技术专家三步破局

破局第一式：执行计划深度CT扫描

GBase技术专家小安立即前往现场对接。小安仔细研究了这张表，这是一张有2亿多条记录约240GB的金融级“巨兽”分片表，在MySQL侧是以月为单位的分片策略，迁移至GBase 8s后，修改为了按照1年为单位的自动分片。

遇事不决先看执行计划，小安了解了表的基本情况之后，查看了这条SQL的执行计划：

从执行计划可以看到，查询走了索引，索引列是ricd，而查询SQL的过滤条件是part_dt和ricd，索引单腿走路引发全分片扫描。此外还存在统计信息陈旧导致优化器误判的问题。

破局第二式：联合索引+统计刷新双引擎启动

小安搭建了一个模拟环境，模拟500万条记录，只查询返回9999条的那一组。

1、精准索引手术：创建组合索引(part_dt,ricd)

2、索引高优操作：通过update statistics更新统计信息

模拟环境实测：500万数据沙盘推演 → 9999条结果0.008秒闪电响应！

破局第三式：生产环境压力熔炉测试

小安将上述方案在实际生产环境中实施，结果发现，虽然生产数据更复杂，但是优化效果仍相当明显，SQL响应时间从原来的55秒降低到0.8秒，在单分片数据量比MySQL还要大的情况下，查询效率与MySQL不分伯仲。

小郑看到秒出的结果，内心兴奋不已，对小安表达了充分的认可与感谢：“国产数据库不仅'能用'，更能'好用'！通过索引策略优化与定期维护，GBase数据库完全具备承载金融级海量数据的能力！”

GBASE有话说

1、对于分区表，通过按照分区字段和主键增加组合索引，并做索引的高优统计更新，性能可以获得明显提升。在实际场景中可以把这个高优操作放在crontab定时任务中，比如每周执行一次。

2、对于自动分片表的索引，由于分片可能成千上万个，建议使用in子句为全局索引。

3、与普通表不同，分片表可以考虑先建索引再导数据；而对于存在追加历史数据，同时在线生产运营的分片表改造，先建索引则是必须的。