 |
1
littlewing May 13, 2020
甲方是爸爸，他们怎么说你怎么来
|
 |
2
mamasan OP @littlewing 事情已经过了, 纯技术方面探讨. 想知道下, 这种大表是否会造成数据库性能的问题. 特别是也有别的项目在同一个数据库上.
|
 |
3
opengps May 13, 2020 via Android
你可以先轻松用表分区来稍微提高下查询效率
|
 |
4
saulshao May 13, 2020
你说的情况,目前的数据量一亿，不会再增加，不分表问题不大。
但是这种事情其实很难预料，也许你的争论对立方掌握了什么你不知道的信息也不一定。 |
 |
5
chiuan May 13, 2020
加索引一般都能满足需求了吧。
|
 |
6
sagaxu May 13, 2020 via Android
你这种情况，分表相当于人工给索引增加一层，能带来什么提升？
|
 |
7
peyppicp May 13, 2020
|
 |
8
index90 May 13, 2020 via iPhone
其实甲方想要的是这个系统可扩容，如果你有扩容方案，不分表也行。
你现在是 sql server，你可以用分区啊 |
|
9
sagaxu May 13, 2020 via Android
sharding 的目的是让数据分布到不同的 instance，一般是不同的 server，多台 server 的 cpu 和 io 能力可以叠加。
同一个 instance 内，有时会分表或分区，比如订单按日期分，由于一般情况只会访问几个月以内的订单，分区做到了冷热数据分离，减少了热数据规模。 但是同一个 instance 内，不区分冷热数据的分表，提升就不太明显了，虽然很多项目都无脑这么做。 |
 |
10
starcraft May 13, 2020 via iPad
甲方居然还会管分表管这么细。一亿数据，只要你说的 ms 不是以千计的那种，那真是吃饱了撑的。建议让甲方派个自己的技术来指导，这个人肯定懂的多，批要求一个个的。
|
|
12
peyppicp May 14, 2020
@sagaxu 大索引命中单条数据硬盘 io 次数不一样吧，一般来讲，按照 mysql 的 b+树， 百万数据 3 次 io，千万数据 4 次 io 了。亿级别的数据 5 次 io
总量没有减少，但是你查询只会落到分片上，不会走所有索引啊。5 次 io 减少到 3 次 io 提升已经很明显了好吧 |
|
13
sagaxu May 14, 2020 via Android
@peyppicp 从 5 次减少到 3 次，得分几千个表了，定位这几千个表本身也是两层查找，总查找层数似乎没有减少。极端情况下，我每 20 条记录分一个表，是不是就只有一次 IO 了？
|
|
14
peyppicp May 14, 2020
@sagaxu 索引键合理的话，千万条以下可以 3 次 io 。
5 次 io 到 3 次 io 要分几千个表，是线上业务中没有走过这块逻辑吧？这种情况下简单分 101 个表就足够了，亿级别数据直接降到百万，不知道你几千个表怎么算出来的。 极端情况不用提了，没啥意义 |
|
15
sagaxu May 14, 2020 via Android
@peyppicp 按一个节点 50 到 100 个算，两层就是 2500 到 10000 。
1. 分 n 个表之后，每个表索引是之前的 1/n 2. n 个分表的总索引大小，跟分表前一样 3. 随机全量查一次每一行，相当于随机遍历索引的每一个节点 4. IO 总量就是索引读取量 5. 索引量一样，所以 IO 量一样 本来有 5 层的时候，如果第 4 层开始频繁出现 cache miss，分表之后，每个表能用的 cache 也要被平分，可能第 3 层就开始频繁的 cache miss 了，均摊下来磁盘 IO 次数并没有减少。 |
Select Language