关于架构师:做好分库分表其实很难之二

7次阅读

共计 1644 个字符，预计需要花费 5 分钟才能阅读完成。

在正式开始之前，菜菜还是要强调一点，你的数据表是否应该分，须要综合思考很多因素，比方业务的数据量是否达到了必须要切分的数量级，是否能够有其余计划来解决以后问题？我不止一次的见过，有的 leader 在不思考综合状况下，自觉的进行表拆分业务，导致的状况就是大家不停的加班，间断几周 996，难道 leader 你不掉头发吗？还有的架构师在一个小小业务初期就进行表拆分，大家为了配合你也是快马加鞭的加班赶进度，上线之后反而发现业务数据量很小，然而代码上却被分表策略牵制了太多。拆表引起的问题在特定的场景下，有时候代价真的很大。
数据库表的拆分解决的问题次要是存储和性能问题，mysql 在单表数据量达到一定量级后，性能会急剧下降，相比拟于 sqlserver 和 Oracle 这些免费 DB 来说，mysql 在某些方面还是处于弱势，然而表的拆分这个策略却实用于简直所有的关系型数据库。

数据库进行表拆分不要太自觉

表的拆分和数据库的拆分有相似之处，然而拆分的规定也有不同。以下的拆分规定针对的是拆分一个表。

横向切分

横向切分是诸多业务中最罕用的切分形式，实质是把一个表中的数据行依照规定扩散到多个表中，比方最常见的依照 ID 范畴，依照业务主键的哈希值等。至于表数据达到什么数量级之后进行切分，这和表中存的数据格式无关，比方一个表只有几列的 int 字段必定要比几列 text 类型的表存储的极限要高。权且认为这个极限是 1000 万吧。然而作为一个零碎的负责人或者架构师来说，当表的数据量级达到千万级别要引起器重，因为这是一个零碎性能瓶颈的隐患。

绝对于数据表的横向切分，在合乎业务优化的场景下我更偏向于做表分区，依照规定把不同的分区调配到不同的物理磁盘，这样的话，业务里的 sql 语句简直能够不必改变。我司的一个 sqlserver 数据库，某个业务的表做了表分区之后，曾经达到几十亿级别的数据量，然而查问和插入速度还是能满足业务的需要（优化一个零碎还是要花精力优化业务层面）。

垂直切分

说到垂直拆分，表也能够依照业务来拆分，比方一个数据库中有用户的信息，依据业务能够划分为根底信息和扩大信息，如果对业务无利，齐全能够拆分为根底信息表和扩大信息表。当然也能够依照别的规定来拆，比方把拜访频繁的信息拆分成一个表，其余不频繁的信息拆分成一个表，具体的拆分规定还是要看过后要解决的问题是什么。垂直拆分可能会引入肯定复杂性，比方原来查问一个用户的根底信息和扩大信息能够一次性查问出后果，分表之后须要进行 Join 操作或者查问两次能力查问出后果。

分表代价

数据表垂直切分之后，原来一次查问有可能会变为连表的 join 查问，在肯定水平上会有性能损失。
数据表横向切分须要肯定的规定，罕用的次要有两种规定：范畴切分和哈希值切分。范畴切分是指依照某个字段的范畴来切分，比方用户表依照用户 ID 来切分，id 为 1 到 10 万的位于 User 表 1 中，100001 到 200000 万的位于 User2 中，这样切分的劣势是，能够有限的扩容上来，不必思考数据迁徙的问题，劣势就是新表和旧表数据分布不平均，而且分表的范畴选取有肯定难度，范畴太小会导致表太多，太大会导致问题基本上没有解决的困惑。另外一种分表策略就是把某一列依照哈希值来路由到不同的表中，同样以用户 ID 为例，如果咱们一开始就布局了 10 个数据库表，路由算法能够简略地用 user_id %10 的值来示意数据所属的数据库表编号，ID 为 985 的用户放到编号为 5 的子表中，ID 为 10086 的用户放到编号为 6 的字表中。这种切分规定的劣势是每个表的数据分布比拟平均，然而前期扩容会设计到局部数据的迁徙工作。
表拆分之后如果遇到有 order by 的操作，数据库就无能为力了，只能由业务代码或者数据库中间件来实现了。
当有搜寻的业务需要的时候，sql 语句只能是 Join 多个表来进行连表查问了，相似的还有统计的需要，例如 count 的统计操作。