共计 2145 个字符，预计需要花费 6 分钟才能阅读完成。
记得，如果有人问你做数据库优化最无效的形式是什么？
SQL 优化、分布式集群、分库分表！干就完了~
但上来就思考分库分表真的适合么，你对分库分表又了解多少呢？什么时候分？有几种分法儿？
首先咱们要晓得分库、分表都是干啥的，本文配角还是咱们的 MySQL 为第一视角。首先从字面意思来看：
分库：
由单个数据库实例拆分成多个数据库实例，将数据分布到多个数据库实例中。
分表：
由单张表拆分成多张表，将数据划分到多张表内。
要晓得，对于大型互联网我的项目，数据量级可能不是咱们能想到的，每日新增数据量过千万是常有的事儿，想靠单台 MySQL 服务器是不事实的。你项羽在牛 B，也顶不住四个队友挂机啊！！项羽：？？？
随着业务数据量和网站 QPS 日益增高，对数据库压力也越来越大，单机版数据库很快会达到存储和并发瓶颈，就须要做数据库性能方面的优化，分库分表采取的是分而治之的策略，分库目标是加重单台 MySQL 实例存储压力及可扩展性，而分表是解决单张表数据过大当前查问的瓶颈问题，坦白说，这些问题也是所有关系型数据库的“硬伤”。
明天咱们就基于常见分库、分表的策略形式以及场景，来搞清楚咱们到底啥时候用的到。罕用策略包含：垂直分表、程度分表、垂直分库、程度分库。
一、朴实无华的 – 分表
1、垂直分表
垂直分表，或者叫竖着切表，是不是感触到该策略是以字段为根据的！次要依照字段的活跃性、字段长度，将表中字段拆分到不同的表（主表和扩大表）中。
特点：
每个表的构造都不一样；
每个表的数据也不一样，有一个关联字段，个别是主键或外键，用于关联兄弟表数据；
所有兄弟表的并集是该表的全量数据；
场景：
有几个字段属于热点字段，更新频率很高，要把这些字段独自切到一张表里，不然 innodb 行锁很恶心的，锁死你呀，如用户表里的余额字段？不，我的余额就很稳固，始终是 0。。
有大字段，如 text，存储压力很大，毕竟 innodb 数据和索引是同一个文件；同时，我又喜爱用 SELECT *，你懂得，这磁盘 IO 耗费的，跟玩儿似的，谁都扛不住的。
有显著的业务辨别，或表结构设计时字段冗余；有些小伙伴看到第一点时，就发现陈哈哈是个菜鸡，用户表怎么会有余额字段？显著有问题啊！连忙先到评论区喷陈哈哈一波，而后笑嘻嘻的发现原来是个小尾巴，真不要脸是吧。。是的，因而不同业务咱们要把具体字段拆开，这样才有利于业务后续扩大哦。
2、程度分表
程度分表，也叫“横着切”。。以行数据为根据进行切分，个别依照某列的自容进行切分。
如手机号表，咱们能够通过前两位或前三位进行切分，如 131、132、133 → phone_131、phone_132、phone_133，手机号有 11 位（100 亿），量大是很失常的事儿，这年头谁家老头老太太每个手机呢是吧。这样切就把一张大表切成了好几十张小表，数据量不就下来了。
有同学就问了那我怎么晓得我这手机号查哪个表呢？一看你就没认真看前两行标红的点，为啥标红嘞？比方我查 13100001111，那我截取前三位，动静拼接到查问的表名上，就行了。
特点：
每个表的构造都一样；
每个表的数据都不一样，没有交加；
所有表的并集是该表的全量数据；
场景：
单表的数据量过大或增长速度很快，曾经影响或行将会影响 SQL 查问效率，减轻了 CPU 累赘，提前达到瓶颈。记得程度分表越早越好，别问我为什么。。
二、花里胡哨的 – 分库
须要你留神的是，传统的分库和咱们相熟的集群、主从复制可不是一个事儿；多节点集群是将一个库复制成 N 个库，从而通过读写拆散实现多个 MySQL 服务的负载平衡，理论是围绕一个库来搞的，这个库称为 Master 主库。
而分库就不同了，分库是将这个主库一分为 N，比方一分为二，而后针对这两个主库，再配置 2N 个从库节点。
1、垂直分库
纵向切库，太经典的切分形式，基于表进行切分，通常是把新的业务模块或集成公共模块拆分进来，比方咱们最相熟的单点登录、鉴权模块。相熟的滋味，记得有一次我把一些没用的表切到一个性能很好的服务器中，这服务器我专门用来学习，起初也不知被哪个狗腿子告密了~
特点：
每个库的表都不一样；
表不一样，数据就更不一样了~ 没有任何交加；
每个库绝对独立，模块化；
场景：
能够形象出独自的业务模块时，能够形象出公共区时（如字典、公共工夫、公共配置等），或者想有一台属于本人的服务器时？
2、程度分库
以行数据为根据，将一个库中的数据拆分到多个库中。大型分表体验一下？坦白说这种策略并不实用，因为会对后盾开发很不敌对，有很多坑，不倡议采纳，了解即可。
特点：
每个库的构造都一样；
每个库的数据都不一样，没有交加；
所有库的并集是全量数据；
场景：
零碎相对并发量上来了，CPU 内存压力大。分表难以基本上解决量的问题，并且还没有显著的业务归属来垂直分库，主库磁盘靠近饱和。
总结
本文就到这里，心愿你学废了！其实，在理论工作中，咱们在抉择分库分表策略前，想到的应该是从缓存、读写拆散、SQL 优化等方面，因为这些可能更间接、代价更小的解决问题。
要记住动表就是动基本，你永远不晓得这张表前面会连带多少历史遗留问题，如果是个很大型的我的项目，遇到些问题你就跟经理提议要分库分表，小心被呼死~
原文链接：https://blog.csdn.net/qq_39390545/article/details/116248222
