已知：索引直接命中，直接出 10 行，查询速度 150ms
你得检查下索引命中情况了，150ms 听着是有 SCAN 的速度

后续表数据量上涨：基于网传 2000w 分表原理，多一层 tree ，实际差距大概是 ms 级的，也就是误差不足 1%，且打满 4 层以前速度不会变。

查询 qps 在 100 左右，索引抽 10 行，这种负载堆到 10 亿也没啥

坏道测试其实价值不大，尤其是 dg 这种不标时间的
smart 为主

授权是个麻烦玩意，尤其是既要又要，还不想遵循现有标准，更麻烦了
spring security 就是个超级大一统框架，要啥有啥，要啥都麻烦，毕竟起夜级定制太多，也能理解
小项目，这些都屌用没有，找个新一些热门一些的库按基本流程去掉一切定制想法，差不多就是 OK 的了

oltp 业务，时间和扫描数据量基本成正比
你这个，扫描数据量上亿，咋个快法？
olap 业务，时间和扫描数据量也是成正比，不过可以通过只扫描必要列、并行扫描多 chunk 并行加速、跳数索引(减少 chunk 数量)、预聚合(无需扫描原始数据)、块压缩(减少 io 时间)等手段来变相超车，减少实际扫描数据量。

分库分表，若依旧单并行顺序执行，不过是把工作拆分，最终时间不变(不考虑 cache)。
若并行查分表，那就是上面的多 chunk 并行加速。

新些的库，比如 polardb ，不开 imci ，只选择并行化，也可以实现相同的效果


mysql ，一些统计性质的聚合函数可以通过索引，能实现类似于“只扫描必要列”的特性

至于你举例这个 sql ，除了有列存优化的库，应该谁跑都差不多才是，都慢

建议裸表直接干，扔掉分库分表中间件

真上亿了，有压力了，你会不知道咋优化？

至于上面推荐 parquet 的，最简单也要有 hive ，查也要有 impala/kylin 之类的引擎，不太推荐。greenplum 是个好东西，不过是 pg 体系的，若是你们用 pg 必然优选这个，etl 更简单。
上 es 的，属于屠龙刀杀鸡，查询也存在割裂，需要研发成本，不推荐。
hbase 的，体系很大，若没有已存在的基础设施，也是不推荐。

我提议按日 etl ，有个前提，超过 n 天的数据无法修改。
每次 etl ，要把这个范围内的日期都 drop part 然后重新 insert 。
若你这个 n ，它很大，那每次 etl 运动数据量很恐怖，clickhouse 这个方案也不太行，建议走 cdc 路子

理智点讲，分两种工况

1. 业务正常读写，能正常跑就单表顶多分区，不建议扯太多。分表增加很多管理压力，而不分表只是 ddl 压力、备份恢复压力。当然前提管住手欠的直接无索引查全表。
2. 有范围聚合性统计操作，这类按惯例，etl 一份到 olap 库，典型目标库 doris/clickhouse ，但这个不要做实时，建议按日，业务侧保证不查当日，或者查询业务上区分当日和非当日。极少有业务无法妥协，不妥协那是人的事不是业务的。
3. 若不能妥协，上游“劳资非要任意查不能拆分”，那就要考虑 cdc 链路，若业务存在 update 则不能选择 clickhouse(细碎麻烦很多，虽然都有解法但太麻烦不适合快速落地)，若业务数据量大(日 300w 不算多，稍微多给点资源就当小量)，doris 配 cdc 合并上也吃不消。至于 cdc 也是有延迟的，分钟级的程度，努努力能做到秒级(十几二十几的程度)，资源消耗究极猛

按日 etl 难度不高，落地很快，配个定时跑下 sql 就能完成入仓。

clickhouse 单机 8c64g 配几块机械盘，足够支撑你这丁丁点数据量(我这单点 ck 每天手机号量级写入)

至于 mysql 插入慢，问题可能多方面。根据描述只能建议先切出 adhoc 查询流量，优化查询体验，没法给你解决写性能问题。

顺带一提，mysql 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”

@shenjinpeng 大概率业务网关、采集、资源下发
高吞吐下 zgc 省心，下限高。g1 上限更高，下限却不怎样

理论应当框架化，实际自研比重相当大
微服务场景，插件化更重要，让各个服务能尽可能便捷接入。
不过公司内技术垃圾，更推荐丢了煞笔的微服务，

给别人打个广告，权限问题可以看一眼 casbin 这个库，功能比较全面，接入尚且算简单。单点登录(第三方登录)还有它家八竿子打不到的 casdoor ，都挺强悍

不考虑实际应用，暴力破解破万法，但实际这玩意得跑到大道都磨灭了

无论什么要求，降噪耳塞只有 3m ，别的基本不用看

按题目数据量级，大概算下来，一年大概 18 万亿行，磁盘空间应该在 1t 到 2t 之间，写入带宽都喂不满一个单点 ck 配几块机械盘
不过列存嘛，整体结构参考上面 @dlmy 兄弟的描述

就这么点数据，想这么多，又这又那的
这点量都摸不到 doris/ck 单机瓶颈

拿 ck 来说，上面给出 ck 表结构的兄弟，@yjhatfdu2 表排序键有问题，排序优先遵循业务必选条件，再根据基数由低到高。建议调整排序顺序为 country,province,city,time 编码方式里，时间去掉 doubledelta ，追求压缩率平衡不用 lz4 ，改用 zstd(1)差不多就这样了。
你这第一个就是高基数，压缩比会很低，速度上不来

对列存来说，整分区 count 都是 O(1)消耗的元数据查询，看不出性能

至于表分区键选用按日还是按月，需要考虑业务平常查询到底按什么的多些。经常跨度大的就改为按月，反之按日。若是业务有按国家为租户的习惯，那分区把国家带上再按月也合理。
若是还有一些大范围时间内区域统计需求，上 projection 来预计算

bps ，timestamp ，时序性数据上时序专用库也可以，总之比这个要好，现在这用法再怎么优化也快不起来的

统计，建议扔了 mysql ，你这场景不适合
考虑 hdfs ，clickhouse ，再来 10 倍量也能秒查