作者：郁光辉，阿里云PolarDB-X技术专家
TTL（Time to Leave）表示数据在表中的生存时间，过期后会自动删除。
实际应用中很多场景下数据与时间强相关，比如订单系统、快递电商系统以及系统日志等。一部分数据有很强的时效性，并且数据会随时间快速增长，热度下降也很快，可能会有点查、范围查询的请求，但该部分请求多访问比较新的数据，老数据很少会被访问到。如果数据一直存储在PolarDB中，会占用表空间，意味着存储成本会上升，且查询效率会下降。
与其一直付出代价维护数据，不如定期将部分数据删除或归档到成本更低的数据库中。比如可以归拢到列存数据库或OSS等系统中，关系型数据库中存储需要查询的较新数据，很少执行的数据存储在冷存储中。
此前，我们比较习惯于比如在MySQL中直接通过 delete+where语句删除数据，但问题在于如果数据规模较大，MySQL会认为这是一条需要全表扫描的SQL，会锁住整个B+Tree，也可能会产生大量Binlog。
因为删数据需要事务性保证，会占用MySQL大量磁盘空间。如果数据量太大，甚至会因为MySQL内存不够导致删失败，是一种比较危险的操作。即使删除成功，B+Tree占用的空间还在，并没有真正释放出磁盘空间，存储成本没有下降。
一般来说，大规模delete语句之后，还需要补充optimize操作，即重建B+Tree，会对所有数据进行搬运，同样可能造成锁表。
因此，我们考虑，是否可以将表空间按照时间进行分区，每个分区包含不同时间范围的数据。但PolarDB-X是分布式数据库，本身具有分区表功能。如上图所示，一张PolarDB-X表已经被按照ID做哈希分为四个分区，数据均匀分布在四个分区中，但是每个分区中的数据包含所有时间范围分区，而我们考虑能否在垂直方向上将每个分区再按照时间进行拆分，即上图中的partition by range columns（date）。
在PolarDB-X分区表基础上，再叠加一层按照时间维度的拆分，直接作用到物理表上。如要删除老分区，只需对每个分区做drop partition的操作，即可实现快速删除的效果。而对于数据库内部来说，这只涉及到元数据操作，并没有真正发生磁盘IO。数据删除之后，后台线程可以慢慢将该部分数据删除，使得delete操作成为比较轻量级的操作。
针对部分不希望被直接删除的老数据，我们提供了数据归档功能，能够将数据归档到OSS存储中，并且提供了一定的存储能力。
PolarDB-X除了支持分区表之外，还支持全局二级索引，且全局二级索引也能够分布在不同数据节点上。因此，全局二级索引也可以看作分区表，数据行数与主表完全一样，只是包含的列数比较少，是主表的子集。
使用TTL表功能可以对几个重要参数进行设定。
• 每个分区的时间粒度：比如天、月、年。
• expireAfterCount：数据过了多少个周期之后自动删除。
• preAllocateCount：提前多少个时间周期创建分区。
• PivotDate：时间基准，即以该时间为基准划定expireAfterCount和preAllocateCount 。默认为当前时间，也可以指定过去或未来的其他时间，可以是用表达式的方式。
上方图示为创建时的场景，下方图示为过了一个时间周期之后，最底下创建出了第十个分区，第一个分区已经过期，会删除或归档到OSS。其本质类似于滑动窗口的结构。
TTL表在PolarDB-X的database有两个模式，分别为DRDS和auto。TTL表只能在auto表中使用，创建方式很简单，只需在正常的create table后跟上TTL特有语法即可。
TTL语法中可以指定7个参数，如图所示，必填参数有两个，其一为希望用哪一列做TTL的分区列，其二为时间分区的间隔。另外，disable schedule指创建表时不要默认自动创建定时任务，如果不加该参数，则默认会自动创建；start with加上日期参数表示TTL表创建时第一个分区的初始时间。我们不希望系统内有些历史数据被放到TTL表中时直接被删除，或很多历史数据归档到会路由到同一分区，这将导致创建出的TTL表的第一个分区会包含非常多的数据。而如果提供了start with，可以将很多早期历史数据按照时间粒度做路由，避免上述情况的发生。
《PolarDB-X开源分布式数据库实战进阶》——PolarDB-X的TTL表的使用和原理（2）： https://developer.aliyun.com/article/1228587?groupCode=polardbforpg
