这是一个创建于 1001 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景是这样的，有一个 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 不高，这种方案是更合适的吗 ？
第 1 条附言 2023-02-14 22:44:19 +08:00
这已经是拆完表之后的条件了，实际数据比这大的多，场景写少读少，就是用户多，用户订单数据不均衡，有需要实时算一些用户的数据，，，
 | 1 Azzsanjin 2023-02-13 22:09:54 +08:00 只插入不更新？要不试试时许数据库 |
 | 2 arloor 2023-02-13 23:45:19 +08:00 via Android clickhouse |
 | 3 LeeReamond 2023-02-13 23:53:59 +08:00 直觉感觉不合适，一般认为 uuid 在 orcale 上是很合适的主键，mysql 则优化很少。不过你们 mysql 能顶到 10 亿数据也挺厉害的。。。 |
 | 4 lingly02 2023-02-14 00:46:03 +08:00 不能做分区表吗 |
 | 5 litguy 2023-02-14 08:18:55 +08:00 @lingly02 他这个不是分库分表的问题，一个用户的所有信息查询，其实 MySQL 不如列式数据库，过去在项目中，也有 10 亿记录查询，匹配某几个关键字的所有记录 fetch 需求，那时候用 Cassandra ，跑得还不错，注意主键设计就好，因为涉及到 data sharding |
 | 6 superares 2023-02-14 08:39:01 +08:00 via iPhone 按照 uid 拆表呢？每一万用户一个表 |
 | 7 imokkkk 2023-02-14 09:01:19 +08:00 MySQL MRR 貌似是解决这种问题的？ |
Select Language