于MySQL数据库的实战运维进程里，伴随业务体量不断增长，当单表数据量达到千万级数目，甚至达到亿级数量时，性能瓶颈就会日益显著地呈现出来。
此时，分区分表分库成为架构设计中不可或缺的一环。
从生产环境实战的角度着手，对那种深入探究水平拆分的落地策略以及该策略所蕴含的核心原理展开探讨，本文会这么做。
何时需要分表分库？
判断标准通常基于两个维度：数据量与并发量。
一旦一张表的数据超出500万行，或者因单表文件体积太大致使IO出现瓶颈，又或者是由于QPS过高使得数据库连接变得紧张时，那么就必然得考虑进行拆分。
常见场景被划分成三类：其一，是针对单表数据量过度庞大致使查询迟缓现象加以解决；其二，是针对高并发写入期间的锁竞争予以解决；其三，是针对单个实例的存储上限进行规避。
分区：逻辑统一，物理分离
分区是MySQL的一种透明存储机制。
针对开发者来讲，所操作的是同一张表，不过MySQL底层把数据分散于不同的物理文件当中。
RANGE分区：适合按日期范围或连续数值拆分。
打个比方说，订单表能够依照create_time来实施分区操作，从而把历史方面的冷数据以及近期的热数据进行物理层面的隔离。
LIST分区：适合按离散值分区，如按地区编码分区。
关键约束：要是表存在主键又或者唯一键，那么所有分区列都务必要是，主键或者唯一键的其中一部分。
这是一个常见的“坑”，设计时需特别注意。
分区具备有效减少IO的作用，举例来说，当呈现只查询某个月的数据这种情况时，仅需要扫描与之对应的分区文件，并非进行全表扫描，是这样的情况。
但它无法解决高并发写入的CPU争用问题。
分表：垂直与水平分割
分表是更彻底的拆分方式，分为垂直分表和水平分表。
垂直分表：将一张宽表按照字段访问频率拆分为多张窄表。
比如说，把文章表之中的标题，正文那样的大字段，跟点赞数，评论数这般的高频访问字段，给分离开来。
这能显著减少单次查询的IO负载。
这有一张表，表中的数据，会依据一个规则（就像按照用户ID取模那样的规则），被分散放置到好多张结构相同的表里，成为分开的表格，这就叫水平分表。
这是处理热数据最常用的手段。
针对那些频繁进行访问的活跃用户所产生的数据，能够将其路由至特定的“热数据表”里头，以此来减少单表的数据量，进而提升索引的效率。
分库：分散写入压力
到了CPU、磁盘 IO 或者连接数量抵达单实例瓶颈之际，便要进行水平分库。
举例而言，原本在同一个数据库内的用户表，会依据以user_id % 4这种方式，被分散开来存至4个不一样的数据库实例里。
具有事务边界，在进行分库之后，跨库的事务会因此而变得复杂，所以需要引入分布式事务，或者采用最终一致性方案。
跨越不同数据库进行查询，应当尽量防止不同数据库之间进行关联查询，常见的做法是通过添加一些冗余字段，或者运用应用层面的聚合操作来予以解决。
实战落地：基于插件的水平拆分方案
在生产环境中，直接修改应用层SQL逻辑侵入性太大。
一般情况下，我们会引入被称作数据库中间件的事物（像MyCAT、ShardingSphere - Proxy这类），或者在应用层引入可用于分库分表的叫做分库分表插件之物（例如ShardingSphere - JDBC）。
策略制定，需挑一持稳固态势的用以区分的关键标识，像订单的身份编号或者用户的身份编号这般的。
该分片键须被所有SQL携带，不然的话，全库表路由会被触发，进而使得性能极其迅速地降低。
2. 数据迁移：采用“双写”或“全量+增量”迁移方案。
首先，开启历史数据导入这个操作，与此同时，借助binlog去监听原库方面的增量数据，最终，将读流量切换至新库。
3. 扩容挑战：取模分片于扩容之际，要迁移数量众多的数据，在此建议运用一致性哈希办法，或者采用时间范围分片方式，以此来避开这一问题。
分区分表分库的协同
分表和分区并不矛盾，而是互补。
针对一张有着极大访问量以及巨大数据量的表，能够先开展水平分表，就像拆分成一百二十八张物理表那样，接着再针对每张物理表依据日期展开分区。
如此一来，便将写入并发问题给解决掉了，同时，单表之内的数据归档以及清理效率也得到了优化。
可对于那种访问量不多然而数据量很大的表，像是日志表这种，单单采用分区就已然足够了，既能够享受到分区裁剪所带来的查询性能方面的提升，又规避了因分表而产生的应用层改造的复杂度。
于架构演进期间，给出这般建议，即是要依照“先对索引予以优化，接着引入缓存，最后的步骤是进行分表分库”这样的原则。
只有在单表索引已然没办法对业务起到支撑作用的情况下，并且硬件资源不能够进行垂直扩展的时候，才慎重地去实施分库分表方案，以此来确保系统拥有高可用性以及可扩展性。
推荐去了解创新互联公司，它专注于数据库架构，还有高可用解决方案，用于网站建设。
Comments NOTHING