十亿 mysql 数据优化，主键能否用 uid+雪花算法 id

[petelin]

背景是这样的，有一个 1T 的数据库，里面有 10 亿条数据， 表结构如下

uid status pay_method refund_status create_time amount device_id xxx

业务上对这个库每天会插入几百完数据，qps 高峰在几百，有一些稍微复杂的查询（主要是会查用户全部的数据），索引不能覆盖全，需要回表的时候，IO 会被打的很高。

select sum(amount) from xx where user_id = xx ,status =xx ,pay_method =xx

（比如这个 sql ，查到 5000 行有效数据的话，需要回表因为数据太过分散，需要去 5000 个 page 上查数据，IO 就会很差，这里 buffer pool 完全存不下 1T 的数据，讨论这种冷用户的查询）

我想的一个解决办法是，把 User_id + 雪花算法 id 当作主键，这样用户的数据都在一起，回表就不需要查 5000 个 page ，顺序 io 小几百就 ok 了。

但是 mysql 主键一般是用自增的当作索引，避免空洞和页分裂，业务场景插入 qps 不高，这种方案是更合适的吗 ？

[Azzsanjin]

只插入不更新？要不试试时许数据库

[arloor]

clickhouse

[LeeReamond]

直觉感觉不合适，一般认为 uuid 在 orcale 上是很合适的主键，mysql 则优化很少。不过你们 mysql 能顶到 10 亿数据也挺厉害的。。。

[lingly02]

不能做分区表吗

[litguy]

@lingly02 他这个不是分库分表的问题，一个用户的所有信息查询，其实 MySQL 不如列式数据库，过去在项目中，也有 10 亿记录查询，匹配某几个关键字的所有记录 fetch 需求，那时候用 Cassandra ，跑得还不错，注意主键设计就好，因为涉及到 data sharding

[superares]

按照 uid 拆表呢？每一万用户一个表

[imokkkk]

MySQL MRR 貌似是解决这种问题的？

[petelin]

@litguy 我再看看 Cassandra ，其实 aws 的 dynamodb 比较合适，可以把 uid 当作分片键，create time 当作主键。uid 数据都在一起可以快速 scan ，也可以加二级索引，而且二级索引还支持带一些额外字段（但不作为索引字段）
你这里说的主键难道就是我想的那样，user_id}_{create_time_random_id} ?