各位老师好，我在想如果是二级索引存在写入热点问题，从tidb的角度来看,目前是不是只有
split table 的方式去打散热点
例如
将索引打散到10个region里面
split table t1 index index_date between 1991 and 2000 regions 10;
将t1表上index_data索引中的1991年到2000年的数据打散到10个region中
但是我有2个思考
1.对于insert造成的写热点，如果二级索引是这种时间类型的字段，是顺序插入的，那么split table 打散索引region 的方法我认为最终来说其实也没啥效果，打散索引的region后，索引还是会递增插入，还是会造成热点
2.对于update 这种热点，我认为可能还是有效果的，如果update 更新的数据总是集中在一些 索引 region 里面，将这些索引region 打散到多个region里面，还是能够有效解决二级索引region 问题
那么目前在不调整索引的情况下，对于这种递增插入造成的二级索引热点，是不是没有很好的方法来解决？
这种情况可以追加考虑采用 hash的方式进行打散，比如
XXX用户 + createTime
XXX用户 + updateTime
这样子，利用 用户的信息，就实现了二次打散，而且索引的更新热点问题也可以得到解决
但是查询时，需要考虑到索引条件的命中
除此之外，还有一些别的方式，原理也类似
哈哈 ，这种递增的就是这样。 插入希望他分开，查询又希望他在一起。
日期基本是存在重复的，这种适用于hash 嘛？
tidb 表示很难
好的，多谢兄弟，但是我这个是写入热点，用load base split 无法解决
索引单调递增引起写入热点问题目前没有特别好的解决方案，像oracle给出的方案是改造索引为 reverse key indexes或者 hash partition the indexes，但是使用上会有一些限制，目前TiDB应该是不支持hash索引
老师，您好，想请问一下，像oracle 这种单机数据库，索引递增插入，插入性能和查询性能应该是比较好把，
oracle这种时间索引，查询性能肯定要好，但是实际插入性能也会受点影响，会产生热块，不然oracle也不会给出反转索引这种解决方法了，但我觉得用时间字段做索引其实有个最大的问题就是如果表大，统计信息不能经常性收集的话，会对相关sql的执行计划产生很大的影响，很多时候会因为统计信息内没有最新时间的信息而自动选择走时间索引，这个可能导致相当大的性能问题。
老师，您好
对oracle 不懂，但是您说的这种，实际插入会产生热快嘛？
oracle 插入的时候 应该也是这种wal 的方式插入的，开始并不直接写到磁盘数据快，这样也会形成热快嘛
一样啊，都是去对region切分
，读写都是对region,所以有用，你去找出写流量高的region就行啊
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
