引荐课程：MySQL教程。
起首数据库是一个软件，最基本的功用就是数据存储和数据查询。关于数据的处置惩罚体式格局假如通泛来讲是分为读和写，所以分布式计划的许多场景实在也是围绕着这两个维度来做的。
在最先分布式计划前，要说下为什么要有分布式计划。假如单机能够处置惩罚的事变，实在完整没有必要去再斟酌分布式了。假如要分，实在就不能再很天然的合起来，这也是分布式计划里须要控制的一个均衡。 如今行业里说的HTAP计划，实在就是融会了OLTP+OLAP的场景，假如从单机的角度来讲，Oracle肯定是最好的HTAP处置惩罚计划了。 然则oracle内里除了价钱的题目以外，另有一个题目，那就是扩大性，暂不说sharding的细节，Oracle内里的设想头脑就是share everything,所以分区表的计划照样比较适宜的。
然则MySQL明显不可，由于你险些听不到互联网行业里在用分区表的计划，由于再怎样分，怎样扩大，数据都是在单机上，何况单机机能还差强人意。 所以单机容量，单机机能都是一个瓶颈，那末就能够有两个或许多个实例来分管压力。
我来简朴举个例子。从数据的处置惩罚角度来讲，数据有读写需求，那末我们的需求就能够离别对读需乞降写需求做扩大。
读需求的扩大相对来讲简朴一些，就是常说的读写分离了。这类平常的中间件都能够支撑。
就如同下图的计划内里的左下角所示，对读的需求能够轻松完成读扩大，这里的读扩大是线性的，不是指数级的，对营业来讲是通明的。
难点就在于写扩大了，写扩大的中心是涉及到分布式事件的部份，能不拆就不拆，假如实在要拆，那末我们能够分差别的维度，比方关于流水型数据，这类数据的前后依赖度很低，所以写需求就是insert，写的需求比较单一。这类体式格局能够运用中间件的计划来辅佐，做到sharding的分片计划。 我们一般明白的分布式计划实在许多也是在说这个。这类计划的扩大是指数级别的，比方2个节点，变成4个，4个变成8个等等，对营业算是通明的。
然则另有一类越发庞杂的，那就是状况型数据，我们不能直接拆，或许说直接分片，我们能够依据营业的维度来拆分，这类拆分就不发起直接运用中间件了。 比方一个营业假如拆分能够拆分为营业1，营业2，营业3。。。营业8，那末这8个营业的拆分逻辑发起不是做成hash的腻滑体式格局，而是发起依据营业逻辑的优先级和其他维度来组合，比方营业1的优先级高，那末完整能够是一个自力的节点，营业3-营业6的数据量和优先级差别，则完整能够是一个节点。数据的写入路由划定规矩发起照样经由过程运用层面来举行处置惩罚。这是一种越发可控的计划。这类扩大计划对运用不是通明的，须要运用的配合和处置惩罚。然则收益也明显是最好的均衡状况，比方游戏行业里很罕见的游戏服观点，就是这类分法，所以扩大起来能够是线性的。
假如要说这个基本之上的分布式计划，实际上是把一套集群或许营业当作一个通明的节点，运用其他的辅佐计划来到达扩大的需求，基于关联型的分布式计划更多是基于静态路由来处置惩罚，关于扩容来讲照样须要做许多分外的事情，没法做到腻滑的弹性。这一点上天然是NoSQL,NewSQL的用武之地了。
所以在计划的挑选上，要有大局观和更高的视野，不一定什么都是MySQL,Oracle，深耕下去天然是不错的，还能够斟酌其他更好的计划。
以上就是mysql支撑分布式吗的细致内容，更多请关注ki4网别的相干文章！
