分区表
大部分数据库都支持分区表，以MySQL为例介绍分区表的主要特性：
在MySQL里，分区表是表的底层组织方式，简单来说，就是把一张表分成几块，每一块存储在磁盘的一个地方，一块也叫做一个分区。比如典型的按月分区，是指每个月产生的数据在一个独立的区域，数据库可以单独处理某一块，也可以多块一起处理。
分区表的优点和缺点如下：
优点
- 显著提高查询性能，因为查询可以只涉及一个或几个分区，无需扫描整个表
- 减少并发竞争，比如操作不同分区的写操作不需要争抢锁
- 支持增量更新，每个分区都可以独立更新
- 适合大数据存储，可将数据分散存储在多个磁盘上，减小磁盘空间的占用和数据传输的时间
缺点： - 分区本身的管理成本:分区的维护需要消耗资源，包括存储空间、内存和 CPU
- 跨分区操作性能很差
- 分区表无法使用外键
一些和时间有明显关系的业务场景，按照时间来进行分区要比直接使用分库分表更加简单高效
2的幂和数据迁移
大厂在容量规划时都是按照2的幂来规划的，比如428，或是8432，而且扩容的时候，也是按照2的幂进行的，基本扩容都选择容量翻倍
原因是：2的特性，在使用哈希取余来进行分库分表的时候，可以使用位运算来计算余数，非常高效。
在扩容的时候，如果扩容为原来的2倍，只需要迁移一半的数据。
面试准备
- 公司分库分表的实际情况，分了几个集群、几个库、几个表
- 核心业务或是维护的业务数据库或数据表的数据量、TPS、QPS
- 是否使用过分区表，按照什么分区的，每个分区数据量是多少
这些数据在面试的时候，要趁机讲出来
- 为什么要分库分表？分区表可不可以？增加从库行不行？
- 什么时候需要分库分表？
- 分库分表的时候，是分库还是分表？还是既分库又分表？
- 分多少库？分多少表？如何计算的？
- 万一容量预估得不准，预估少了怎么办？
其他问法：
如果数据库已经到了写瓶颈怎么办？优化写操作或分库
如果数据库已经到了读瓶颈怎么办？优化读操作或加从库或分库或分表
基本思路
起点是：为什么分库分表
如果项目经历里和数据库有关，看起来可以用分区表得内容，就会问：为什么要分库分表？分区表能不能解决问题？
为什么分库分表
数据库遇到了性能瓶颈
一句话总结分库分表，那就是数据库本身出现了性能问题，而且这些性能问题已经没办法通过SQL优化、索引优化之类的手段解决了
进一步将分库分表和 分区表、读写分离进行对比，从硬件资源、并发、数据量 三个引起性能瓶颈的角度去分析
在分库分表之前优先考虑分区表和读写分离，因为这两种方案和分库分表比起来都更简单、好维护
如果是数据库本身硬件资源不足，那么不管是分区表还是读写分离都难以解决问题。比如数据库网络带宽不够了，分区表肯定解决不了；如果是写操作引发的网络带宽不够，读写分离增加从库也没法解决。
如果是并发引起的问题，那么分区表和读写分离也不太能解决。比如表锁，读写分离是没法解决的，就算增加100个从库，表锁还是都在主库上。分区表虽然因为有分区，可以减少并发竞争，但是如果某一个特定分区上已经遇到写瓶颈了，那么分区表也没用。
如果单纯因为数据量过大而引起的性能瓶颈，读写分离也不太能解决。举个例子，加入一个表有几千亿条数据，显然无论怎么加从库，单一一个查询都会很慢，如果数据量大到索引都无法放进内存，查询性能会极差。
对于写瓶颈来说，分区表可以缓解问题，而读写分离几乎没有效果，比如频繁地增删改操作。对于硬件瓶颈来说，读写分离、分区表基本上也解决不了，比如写操作引发的网络带宽问题。
总结：业务已经触及了主库写性能瓶颈
我们这个业务数据库逼不得已要分库分表的原因就是主库现在已经不堪重负，可以认为 TPS 已经触及到硬件天花板了。虽然理论上我们还是可以购买更强的服务器来部署数据库实例，但是实在太贵了，而且业务增长也还是会触及新机器的性能瓶颈，那么索性分库分表一步到位。我们还准备了其他主从集群，将分库之后的数据库分散在不同的主从集群上，或者说分了数据源。
当然，并不是说分库分表之后就不能使用读写分离。实际上分库分表的数据库集群一般也是主从集群。不过分库分表和分区表混合使用的情况比较少，但理论上也是可行的。
问题的本质 关键词就是性能瓶颈
目前业界有很多公司会出一些最佳实践之类的手册，告诉你数据量超过多少多少就要分库，比如说行数超过多少行，或者数据量超过多少 G 就要分表。
但是这些最佳实践其实是一种偷懒的说法，是我们在日常实践中总结出来的很多表在这么一个量级下就会出现性能瓶颈。所以归根结底要不要分库分表，只需要看有没有性能瓶颈。
而且但凡性能瓶颈可以用分区表或者读写分离解决，就不要着急使用分库分表。当然，如果用得起 Oracle 数据库，那就根本不需要分库分表了。
分库还是分表
三个原则：
- 如果是数据库本身的硬件资源引起的性能瓶颈，就要分数据源，有更多的主从集群
- 如果是逻辑数据库引起的性能瓶颈，只需要在逻辑数据库这层分库
- 如果是单表数据量过大、锁竞争等跟表维度相关的资源引发的性能问题，分表就可以了
容量估算
主要依据两点：现有数据和增长趋势
存量数据
是最好处理的，但是不是所有的存量数据都需要进行分库分表，部分不重要的、用不上的、历史悠久的数据，不如直接归档或是放到大数据平台上。真正需要计算的是那些线上继续查询的数据的量
增长趋势
计算难点，需要考虑现有数据增长率和数据增长率的变化趋势，也就是数据量的一阶导数和二阶导数。主要看公司的规划
数据的增长趋势只需要根据公司的战略规划来就可以。比如说今年公司的目标是业务翻倍，那么就可以认为今年数据的增长率是 100%。就算公司没有发布这一类的规划，但是产品经理肯定是背着 KPI 的，问一下他们也就知道了。不过正常来说，一家公司都是有三五年规划的，照着规划来预估容量就可以了。
因为扩容非常复杂繁琐，所以可以补充容量预估的原则 – 宁滥勿缺
大体上，预估要料敌从宽，也就是按照业务可能的增长上限来评估。因为万一容量预估少了，还需要再扩容，这就比较麻烦了。
只需要预估未来三年就可以。但是有些公司很有钱同时害怕扩容，所以一开始可能就留足了余量，所以可以满足数十年的需要。
正常来说，预估容量需要考虑未来三年的数据增长情况，只需要确保三年内不会触发扩容就可以。但是三年也不是一个硬性标准，比如说有些公司比较害怕扩容，那么可能直接预估了五年、十年的容量。
扩容亮点
扩容本质上是两件事：扩容后的容量评估和数据迁移
容量评估这个步骤要比初次分库分表简单得多，基本上都是按照 2 的倍数来进行扩容
就容量评估来说，因为已经分库分表了，所以只需要按照已有容量的 2 倍来扩容就可以了。比如说现在是分了 4 个库，每个库 8 张表，那么就可以考虑扩容为 8 个库，每个库 8 张表；也可以考虑扩容成为 4 个库，每个库 16 张表。当然，直接扩容到 8 个库，每个库 16 张表也是可以的。
这里留了一个引导点，就是什么时候扩容库，什么时候扩容表？这个问题可以参考前面分库还是分表这部分知识来回答，它们本质上是同一个问题
如果面试官问到能否缩容，那么你就可以这么回答：
理论上是可以的，而且和扩容差不多，都是要解决容量问题和数据迁移问题。
数据迁移
过程和之前的基本一样，唯一有区别的地方是不管操作源表还是目标表，都是需要按照分库分表的规则进行，基本可以复用之前的数据迁移方案。
补充一个更加高级的数据校验方案：流量复制与重放
就算你所在的公司没有类似的实践，你也可以跟面试官聊，因为除了少部分大厂做得还可以，其他公司基本上都没做过，或者做得很差
方案的原理：在保持以源表为准的双写阶段，录制线上的 HTTP 请求，然后再异步重放。拿到原本 HTTP 请求的响应和重放的响应，做一个比较
面试谈到数据校验的时候，你可以介绍一下这个方案，不过不建议你说自己用过这个方案，因为里面细节比较多，很容易翻车。这里我用一种设计了这个方案，但是因为复杂度过高所以没有实施的话术来介绍，关键词是流量录制和重放
在数据校验上，最开始的时候我设计过一个利用流量录制和重放来做数据校验的方案，真正从业务逻辑上校验数据的准确性、完整性和一致性。整体思路是在 HTTP 入口处引入一个流量复制组件。当有读请求过来的时候，就会把请求整体录制下来，然后异步地重放请求，再把重放请求的响应和原始响应进行对比，判断数据迁移有没有出错。
一般来说就是使用 tcpcopy 或者 goreplay。有时间你可以去了解一下这两个中间件，学会如何使用就足够了
这个数据校验方案有很多可以深挖的地方，所以你可以继续引导。
这个方案还是有比较多的问题，比如说 HTTPS 的问题、并发的问题
去除HTTPS
第一个问题是要解决流量复制过程中HTTPS协议的问题，基本都是在去除了HTTPS协议之后才开始录制流量的。简单来说就是放在了网关之后，网关会把HTTPS协议转成HTTP协议，这样就可以录制流量了
我这个方案是准备在 Nginx 后面接入流量复制。用户和 Nginx 之间是 HTTPS 通信，但是 Nginx 和后面的服务器之间是 HTTP 通信，所以就可以避开 HTTPS 的问题。
并发问题
设想这样一个场景：
这种假阳性问题，本身数据是一致的，但是因为并发问题，导致校验误报了。这种并没有什么影响，因为修复数据的时候，我们永远都是用源表最新的数据去覆盖目标表最新的数据，这种假阳性就是白做了修复的工作而已。
虽然这里有可能出现假阳性的问题，不过不足为惧，因为本身数据是一致的，而且假阳性很少出现，因为我们的业务就是一个读多写少的场景。并且流量也不打算 100% 复制，只是小比例复制流量就可以了。
面试技巧：通过介绍一个高端但是没有实施的方案，进一步加深面试官对你的印象
399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
