EsgynDB 关于带索引的DELETE性能提升

最新推荐文章于 2023-12-26 14:49:59 发布

原创

最新推荐文章于 2023-12-26 14:49:59 发布 · 1.6k 阅读

在钱库版EsgynDB中，针对有索引表的DELETE操作性能进行了显著优化，通过采用批量删除方式，将原本超过两小时的删除时长缩短至21秒，极大提升了数据库操作效率。

EsgynDB在金融行业的分支版本钱库（QianBase）已经问世有段时间，在钱库版本中，对相关的功能、性能部分做了大量的增强。这其中包括插入、更新及删除的性能提升。

在早期的版本中，当目标表只有主键的情况下，EsgynDB的增删改的性能是相当不错的，因为默认情况下执行计划走的是批量提交的方式，在执行计划中我们可以看到诸如VSBB_UPSERT、VSBB_DELETE这样的字眼，VSBB即批量执行。但当表上有一个或多个索引的时候，相比较于没有索引的情况下，性能会下降很大。

针对此问题，钱库中做了相关的性能增强，包括插入、更新及删除，都做了相应的增强。关于插入和更新，我们会在后续文章中慢慢介绍，本文中我们先对比一下DELETE的性能提升。

在早期版本中，在有索引的表上做DELETE操作时，对于表记录的删除，执行计划并没有采用VSBB_DELETE，而是走TRAFODION_DELETE，这严重限制了删除的性能，以下是一个DELETE有索引表的执行计划，

LC   RC   OP   OPERATOR              OPT       DESCRIPTION           CARD
---- ---- ---- --------------------  --------  --------------------  ---------

5    .    6    root                            x                     1.19E+006
3    4    5    nested_join                                           1.19E+006
.    .    4    trafodion_vsbb_delet            IDX_TEST_DELETE       1.00E+000
1    2    3    nested_join                                           1.19E+006
.    .    2    trafodion_delete                TEST_DELETE           1.00E+000
.    .    1    trafodion_scan                  TEST_DELETE           1.19E+006

虽然对于索引的执行计划是TRAFODION_VSBB_DELET，但由于对于主表的删除是TRAFODION_DELETE，导致语句执行效率相当低下，从以下运行时的统计信息可以看出，EX_TRAF_DELETE的OperCPUTime是71,645,451。此表总记录数100万，删除记录为99万多，删除时长超过2小时未结束。

>>get statistics for qid current default;
Qid                      MXID11000016667212447900982995646000000000206U3333302T000_335___SQLCI_DML_LAST__
Compile Start Time       2020/02/08 14:11:01.268632
Compile End Time         2020/02/08 14:11:01.279867
Compile Elapsed Time