需求反馈
【需求涉及的问题场景】
截止到TiDB8.1,目前支持的表达式索引支持的函数较少,希望支持时间相关的函数,如DATE
等。
【期望的需求行为】
希望表达式索引支持时间相关的函数,如DATE
等。
【需求可替代方案】
暂无
【背景信息】
对datetime字段类型插入大量连续数据时,使用date
表达式索引比直接在datetime字段建索引,减少了写入时的索引热点。
需求反馈
【需求涉及的问题场景】
截止到TiDB8.1,目前支持的表达式索引支持的函数较少,希望支持时间相关的函数,如DATE
等。
【期望的需求行为】
希望表达式索引支持时间相关的函数,如DATE
等。
【需求可替代方案】
暂无
【背景信息】
对datetime字段类型插入大量连续数据时,使用date
表达式索引比直接在datetime字段建索引,减少了写入时的索引热点。
内部已经收到,会有相关 PM 统一规划。
请问这个是啥原理呢
你好,能描述展开描述一下业务场景么?因为维护表达式索引的代价比一般的索引更高,当查询速度比插入速度和更新速度更重要时,会推荐建立表达式索引。
场景主要是基于时间过滤数据,datetime字段是递增的(精度至少是毫秒或者微秒),直接在datetime建立索引每时每刻都会有热点,无法解决,如果使用DATE 表达式索引,会将这个索引的精度限定在天维度,这个场景下可以接受以天为精度过滤,也就是索引的key是由以下元素组成
日期天+随机主键id
那在这一天内这个索引都不会产生热点,只有日期切换的时候会有一小段时间产生热点,因为日期更大了。使用DATA_FORMAT 的话可以自由控制精度,比如小时,但热点的情况就是每个小时更替的时候会出现。
索引原理的参考了这个文档 https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-编码规则回顾
虽然官方没有写支持DATE或者DATE_FORMAT表达式索引,内部也实测试过了是可以用的,也符合我们的预期,延迟方面增加的不多,想官方确认下这个表达式是否稳定可用
如果不用表达式索引,可以试下按天的 range 分区表,或者数据多冗余一列 date 类型的列,在这个上边建立你那个索引
单独加多一个date 列成本比较高,原表已经存在datetime 字段的了~