关键字：
KingbaseES、MVCC、数据快照、快照过期、人大金仓
1、应用演示
在人大金仓的数据库产品中（单机的KingbaseES，读写分离的RWC，共享存储的RAC），也引入了MVCC和快照过期的特性。
在kingbase.conf中搜索关键字可以找到old_snapshot_threshold，根据需要配置参数的值，配置区间：-186400；-1代表不过期；0代表立刻过期；186400，过期时间，默认单位为分钟，也可以配置为Xh或Xd这样的格式，按小时或天为计量单位，最大过期时间不大于60天即可。
同时根据实际使用，还需要配置参数autovacuum，开启自动回收垃圾数据，才能确保环境中的长事物占用的数据不会造成数据库数据膨胀。
特性生效验证：
- 修改kingbase.conf文件，开启old_snapshot_threshold；
- 重启数据库；
- 查看相关配置是否生效；
（执行语句“show old_snapshot_threshold;”，可以查看当前数据库的快照过期配置）
- 数据库里创建表t1，并插入数据；
- 执行一个长查询事物
（示例中通过查询中加入sys_sleep()参数实现放慢业务处理速度的效果）
- 另起一个连接，清除t1的数据
- 手动回收t1表的死元组数据(需要多次执行)
（等待快照过期配置的时间生效后，可以看到数据被回收，长查询事物失败，生成error级报错，ERROR:snapshot too old）
2、应用细节
验证功能时发现，长事务失败报错的时间和old_snapshot_threshold参数配置时间不一致，要比快照过期时间大一些？
这是因为查询类长事务在执行时会对数据进行分页，一次性获取一整页的数据缓存，当缓存数据处理完毕时，才会再次获取下一页数据的缓存，此时事务获取数据失败，数据快照早已按照过期配置清理。
案例1：
在第二张图中，可以明显看到600条数据的长查询中的数据被分为了3页，其中第一页因为缓冲区，在回收数据时被跳过，快照过旧发生在长查询完成对第一页数据完成处理，调用第二页数据时（此时被查询数据已经过期，且被回收）。
案例2：
在第二张图中，可以明显看到100条数据的长查询中的数据仅占用1页，其中第一页因为缓冲区，在回收数据时被跳过，长查询完成对第一页数据处理，打印事物结果，快照过旧无法发生（被查询数据已经过期，且被回收，但是缓存确保了事物的完成）。
