学习一下
大时间范围的扫描，难
走tiflash吧
分区吧
以createTime 按天range分区感觉可行
region打散，再加上分区，索引设计合理一点，不一定要跟mysql的完全一样，结合tidb的优点建，效率应该是没问题的
1 个赞
还是要用上效率比较好的字段做索引
1天才1一个亿吗，这个查询结果是多少
一天大概就是一亿,高峰期大概4亿，这个结果几十万吧。
1 个赞
用 TiKV 查 count(1) 也应该很快就出来了，正常官方推荐的最小配置肯定到不了 10S，我觉得 5 S都到不了 ，具体多快你得测试下，普通表的话建立一个 (no, createTime ) 复合索引,如果分区表的话，建议按天做范围分区，索引只建立 no 列就好了
count(1) where 条件只带createtime会很快，带上no列就很慢，需要回表。no这一列区分度比较低，建索引意义不大。
把 no 字段也加到索引里就不会回表了啊 
，另外 no 过滤行为啥不强呢，你不是一天一个亿数据吗，你 SQL 查的不也是 1 天的吗，不加 no 不应该返回一个亿吗
不加no获取当天总数，加no过滤出来一部分数据。
一个表有十几列，除了createtime是必选的，其他列任意组合，总不能每一列都加索引吧。
你要随意变字段就没法建立合适索引，如果有几列是可能的，那还能建联合索引，能接受 insert 慢就好，实在定不了就只能按天分区表走 TiKV ，再不行就上高版本 TiFlash 吧，效率会高一些
1 个赞
所以我建议用联合索引，不用回表
KEY idx_createTime (createTime,no),
你这一个表的需求。不适合放tidb集群里。别因为一个表，拖累了其它功能模块！
分区裁剪。。可以试试
这种索引的模式（time，no）好像有问题。
explain的时候看到只扫描了time 并没有扫描no，如果把no放前面（no，time），那么就会扫描两个字段的交集范围。
不知道为什么时间字段放前面会有这种情况。