分布式数据库mysql
当前做分布式的厂商有几家，我知道比较出名的有“华为云分布式数据库DDM”和“阿里云分布式数据库”，感兴趣可以自行搜素了解下。
分布式数据库的几点概念可以了解一下。
数据分库：
以表为单位，把原有数据库切分成多个数据库。切分后不同的表存储在不同的数据库上。
以表中的数据行记录为单位，把原有逻辑数据库切分成多个物理数据库分片，表数据记录分布存储在各个分片上。
路由分发：
在分布式数据库中，路由的作用即将SQL语句进行解析，并转发到正确的分片上，保证SQL执行后得到正确的结果，并且节约QPS资源。
读写分离：
数据库中对计算和缓存资源消耗较多的往往是密集或复杂的SQL查询。当系统资源被查询语句消耗，反过来会影响数据写入操作，进而导致数据库整体性能下降，响应缓慢。因此，当数据库CPU和内存资源占用居高不下，且读写比例较高时，可以为数据库添加只读数据库。
B. 数据库都有哪些
一、数据库种类有哪些
早期较为时兴的数据库种类有三种，分别是层次式数据库、网络式数据库和关系型数据库。而在如今的互联网中，最常见的数据库种类主要有2种，即关系型数据库和非关系型数据库。
二、层次数据库介绍
层次数据库是最开始研制的数据库系统软件，它把数据根据层次构造（树结构）的方法呈现。层次数据库以前是非常热门的数据库，但伴随着关系数据库的逐渐流行，如今早已非常少应用了。
较为具备象征性的层次数据库是IMS（Information Management System）数据库，由IBM企业研发。
三、关系型数据库详细介绍
网络数据库和层次数据库在数据独立性和抽象性级别上有所欠缺，用户开展存储时，需要声明数据的存储结构和相对路径。而关系数据库就可以较切实解决这种问题。
和Excel工作簿一样，关系型数据库也选用由列和行构成的二维表来管理数据，简单易懂。另外，它还利用SQL（Structured Query Language，结构化查询语言）对数据开展实际操作。
四、非关系型数据库详细介绍
伴随着互联网技术Web2.0的兴起，传统关系型数据库在应对大数据量，比如大规模和高并发的微博、微信或者SNS类型的web2.0动态网页时，已经有些力不从心，曝露了许多难以克服的难题。因此出现了针对大规模数据量场景，以性能卓越和应用便捷为目的的的数据库产品——NOSQL数据库。
C. Mysql Cluster 与 OceanBase 有哪些区别哪个更优秀
1. 分布式存储部分是做为mysql的一种存储引擎实现的（NDB），上层SQL没有感知，所以SQL层应该没有支持分布式并行查询处理。OceanBase的基于代价的查询优化器对于大查询会充分发挥分布式数据库的并行处理能力。再如OB分布式执行计划可以下压到存储所在机器。而ndb node实现存储引擎接口没有复杂的查询处理能力。
2. Mysql cluster中主备同步是用两阶段提交实现的，这个有点无语。另外REDO日志异步写入，延时一秒。也就是说宕机会丢一秒的事务，想象一下双十一每秒17万笔交易丢失……这块是它的整体架构导致事务层实现机制的问题。
btw，mysql cluster属于分布式数据库，mysql主从几节点都不是分布式数据库。
D. 国内做MySQL分布式数据库厂家有哪些
国内的数据库厂家有很多，像万里开源、创意信息、南通、神通等。
其中万里开源是前MySQL中国研发中心，先后与MySQL AB、SUN、Oracle合作研发过MySQL核心代码。与MySQL联合研发期间主要的贡献集中在Replication复制模块与NDBCluster模块，对分布式数据库集群的研发和经验积累已经有约14年，对MySQL内核以及分布式数据库集群有着深刻的理解与技术沉淀，目前拥有约80余项技术专利与软件着作权。目前万里开源具有员工180+人，其中数据库技术团队约100+人，技术团队的组成以985和211毕业生为主。
而且，万里开源还是创意信息控股的子公司，创意信息技术股份有限公司（股票代码：300366）成立于1996年，2014年在深交所创业板上市，总部位于成都。依托上市公司资源，
无论从公司实力还是研发背景上来看，万里开源都是一家做分布式数据库不错的公司。
E. TDSQL TCA 分布式实例特点初探分布表和SQL透传
TDSQL分布式实例通过Proxy接口提供和mysql兼容的连接方式，用户通过IP地址、端口号以及用户名、密码进行连接：
（注意：公有云TDSQL需要在实例页面申请公网连接地址）
连接示例：mysql -h172.21.32.13 （proxy地址） -P3306（proxy端口） -utest （数据库账号） -p
与普通的mysql连接方法一致，分布式实例兼容mysql的协议和语法，支持SSL加密等功能。当然，您也可以使用navicat、 jdbc、 odbc、 php、 Python等来连接分布式TDSQL实例。
1、TDSQL分布式实例支持表的类型介绍
a、分布式表： 即水平拆分表，也成为“分表”，该表从业务视角是一张完整的逻辑表，但后端根据分表键（shardkey）的HASH值将数据分布到不同的物理节点组（SET）中。
b、普通表： 又名Noshard表，即无需拆分的表，和传统集中式数据库中的表一致，且没有做任何特殊处理的表，目前分布式实例将该表默认存放在第一个物理节点组（set）中。
c、广播表： 又名小表广播技术，即设置为广播表后，该表的所有操作都将广播到所有物理节点组（set）中，每个set都有该表的全量数据，常用于业务系统关联查询较多，修改较少的小表或配置表等。
表类型选用注意事项：
在分布式实例中，如果两张表分表键相等，这意味着两张表**相同的分表键对应的行**，存储在相同的物理节点组中。这种场景通常被称为组拆分（groupshard）,会极大的提升业务联合查询等语句的处理效率。由于单表默认放置在第一个set上，如果在分布式实例中建立大的单表，则会导致第一个set的负载太大。除非特别需要，在分布式实例中尽量使用分布式表，这也是分布式实例的特点之一。
2、TDSQL分布式实例表的创建
接下来我们来看下分布式数据库TDSQL所支持的三种类型表的使用方法和注意事项。
a、分布式表的使用
简述：普通的分表创建时必须在最后面**指定分表键（shardkey）的值，该值为表中的一个字段名字，会用于后续sql的路由选择。连接到TDSQL分布式实例后，我们创建一个本次操作使用的数据库名为：testdb
mysql> create database testdb;
mysql>use testdb;
接下来我们创建分布式表，命名以分布式拼音首字母命名
**建表语句1：**
MySQL testdb> create table fbs ( a int, b int, c char(20),primary key (a),unique key u_1(a,c) ) shardkey=a;
Query OK, 0 rows affected (0.07 sec)
**建表语句2：**
MySQL testdb> create table fbs2 ( a int, b int, c char(20), primary key (a,b) ) shardkey=a;
Query OK, 0 rows affected (0.09 sec)
b、广播表的创建
简述：支持建小表（广播表），此时该表在所有set中都是全部数据，这个主要方用于跨set的join操作，同时通过分布式事务保证修改操作的原子性，使得所有set的数据是完全一致的 。
**语句：**
MySQL testdb> create table gbb(a int,b int key) **shardkey=noshardkey_allset;**
Query OK, 0 rows affected (0.03 sec)
c、传统普通表
简述：支持建立普通的表，语法和传统mysql完全一样，此时该表的数据全量存在第一个set节点中，所有该类型的表都放在第一个set中。
MySQL testdb> create table ptb(a int ,b varchar(10));
Query OK, 0 rows affected (0.03 sec)
注意事项：
1、在分布式实例中，分布式表shardkey对应后端数据库的分区字段，因此必须是主键以及所有唯一索引的一部分， 否则可能无法完成建表操作。
2、分布式表shardkey字段的值不包含中文, 否则proxy会转换字符集可能会出错。另外SQL语法上如：shardkey=a 一般放在SQL语句最后来写。
3、TDSQL分布式实例表的数据操作
为了更好的发挥分布式架构的优势，在进行SQL操作时和传统数据库还是有部分差异。接下来我们从数据库的插入，更新，删除方面分别来看有哪些注意事项。
======INSERT插入操作=======
**插入语句1：**
MySQL testdb> insert into fbs(a,b) values(10,1000);
Query OK, 1 row affected (0.00 sec)
**插入语句2：**
MySQL testdb> insert into fbs values(1,10,1000);
或
MySQL testdb> insert into test1 (b,c) values(100,"record3");
ERROR 810 (HY000): Proxy ERROR:sql is too complex,need to send to only noshard table.Shard table insert must has field spec
注意：语句2报错的原因insert时字段需要包含shardkey，否则会拒绝执行该sql，因为Proxy不知道该sql发往哪个后端分片节点。
=====UPDATE、DELETE更新、删除操作=====
更新语句1：
MySQL testdb> update fbs set b=2000 where a=10;
Query OK, 1 row affected (0.00 sec)
更新语句2：
MySQL testdb> update fbs set b=2000 ;
ERROR 658 (HY000): Proxy ERROR: Join internal error: update query has no where clause
删除操作：
MySQL testdb> delete from fbs;
ERROR 913 (HY000): Proxy ERROR:Join internal error: delete query has no where clause
注意事项：
1、出于数据操作安全上和减少人为误操作导致数据丢失情况的出现，TDSQL禁止update 无 where 条件的更新动作。
2、同样的delete操作无where条件也会被禁止执行，如果确认要删除表数据或表，建议备份后用truncate或drop方式操作。
3、同样的update操作时尽量避免更新shardkey字段，因为影响Proxy中的路由更新，会导致错误。
1、TDSQL透传功能介绍
对于分布式实例，会对SQL进行语法解析，有一定的限制，如果用户想在某个set中获取单个节点数据，或在指定节点执行SQL，可以使用TDSQL的透传SQL的功能。
使用透传功能，我们需要重新连接登录TDSQL分布式实例时指定 **- c选项**。普通登录方式，不支持指定节点执行SQL的透传功能。
登录如下：
mysql -h172.21.32.13 （proxy地址） -utest -P3306 -p -c(透传必须指定-c)
2、TDSQL透传操作演示
首先我们重新登陆TDSQL分布式实例： mysql -h172.21.32.13 -utest -P3306 -p -c
仍旧切换使用testdb数据库。
a、查看分布式实例set节点
使用/*proxy*/show status 查看当前的TDSQL分布式实例的节点信息，共有两个set ，分别为set_1605181898_1、set_1605181972_3
MySQL testdb> /*proxy*/show status ;
+-----------------------------+-------------------------------------------------------------------+
| status_name | value |
+-----------------------------+-------------------------------------------------------------------+
| cluster | group_1605181791_302290 |
| **set_1605181898_1:ip | 10.53.179.14:4322;[email protected]:4322@1@IDC_GZ_YDSS0301_79263@0 |
| set_1605181898_1:hash_range | 0---31 |
| **set_1605181972_3:ip | 10.53.179.14:4323;[email protected]:4323@1@IDC_GZ_YDSS0301_79263@0 |
| set_1605181972_3:hash_range | 32---63 |
| set | set_1605181898_1,set_1605181972_3 |
+-----------------------------+-------------------------------------------------------------------+
6 rows in set (0.00 sec)
b、演示数据插入
我们针对之前创建的fbs分布式表进行数据的插入
MySQL testdb> insert into fbs(a,b,c) values(10,1,'AAA'),(20,2,'bbb'),(30,3,'ccc'),(40,4,'dddd'),(50,5,'eee'),(60,6,'fff'),(70,7,'ggg'),(80,8,'hhhh');
MySQL testdb> select * from fbs order by 1;
+----+------+------+
| a | b | c |
+----+------+------+
| 10 | 1 | AAA |
| 20 | 2 | bbb |
| 30 | 3 | ccc |
| 40 | 4 | dddd |
| 50 | 5 | eee |
| 60 | 6 | fff |
| 70 | 7 | ggg |
| 80 | 8 | hhhh |
+----+------+------+
8 rows in set (0.00 sec)
c、透传查看数据在各个节点的分布情况
MySQL testdb> /*proxy*/show status;
+-----------------------------+-------------------------------------------------------------------+
| status_name | value |
+-----------------------------+-------------------------------------------------------------------+
| cluster | group_1605181791_302290 |
| **set_1605181898_1:ip | 10.53.179.14:4322;[email protected]:4322@1@IDC_GZ_YDSS0301_79263@0 |
| set_1605181898_1:hash_range | 0---31 |
| set_1605181972_3:ip | 10.53.179.14:4323;[email protected]:4323@1@IDC_GZ_YDSS0301_79263@0 |
| set_1605181972_3:hash_range | 32---63 |
| set | set_1605181898_1,set_1605181972_3 |
+-----------------------------+-------------------------------------------------------------------+
6 rows in set (0.00 sec)
查看数据在set_1605181898_1 节点上的分布
MySQL testdb> /*sets:set_1605181898_1*/select * from fbs order by 1;
+----+------+------+------------------+
| a | b | c | info |
+----+------+------+------------------+
| 10 | 1 | AAA | set_1605181898_1 |
| 30 | 3 | ccc | set_1605181898_1 |
| 40 | 4 | dddd | set_1605181898_1 |
| 50 | 5 | eee | set_1605181898_1 |
| 80 | 8 | hhhh | set_1605181898_1 |
+----+------+------+------------------+
5 rows in set (0.00 sec)
查看数据在set_1605181972_3节点上的分布
MySQL testdb> /*sets:set_1605181972_3*/select * from fbs order by 1;
+----+------+------+------------------+
| a | b | c | info |
+----+------+------+------------------+
| 20 | 2 | bbb | set_1605181972_3 |
| 60 | 6 | fff | set_1605181972_3 |
| 70 | 7 | ggg | set_1605181972_3 |
+----+------+------+------------------+
3 rows in set (0.00 sec)
d、通过shardkey分片号查看数据
MySQL testdb> /*shardkey:2*/select * from fbs order by 1;
+----+------+------+
| a | b | c |
+----+------+------+
| 20 | 2 | bbb |
| 60 | 6 | fff |
| 70 | 7 | ggg |
+----+------+------+
3 rows in set (0.00 sec)
支持透传种类和格式：
1、set名字可以通过/*proxy*/show status查询
2、/*sets:set_1名称*/ 透传指定节点
3、/*sets:allsets*/ 透传所有节点
4、/*shardkey:10*/ 透传到shardkey分片对应的set
5、支持透传sql到对应的一个或者多个set
分布式表的DDL部分的语句限制：
暂不支持CREATE TABLE ... LIKE
暂不支持CREATE TABLE ... SELECT
暂不支持CREATE TEMPORARY TABLE
暂不支持CREATE/DROP/ALTER SERVER/LOGFILE GROUP/
暂不支持ALTER对分表键(shardkey)进行重命名，不过可以修改类型
分布式表的DML部分的语句限制：
暂不支持SELECT INTO OUTFILE/INTO DUMPFILE/INTO LOAD DATA导出
暂不支持INSERT ... SELECT
暂不支持UPDATE 分布式shardkey列的值
本操作主要是面向传统数据库的开发者或者DBA用户，让大家能够初步入手了解分布式数据库的特点。另外分布式数据库在架构上提供了灵活的读写分离模式，在SQL上支持全局的order by， group by， limit操作，支持聚合函数，跨set节点的join、子查询、支持分布式事务，传统数据库所支持的大部分操作在分布式数据库中得到继承。分布式数据库是在传统数据库的基础之上发展起来的，对传统集中式的数据库有较好的兼容性，对SQL语句语法的使用上兼容大部分SQL1999,SQL2003标准，且对SQL的ACID特性都予以支持。分布式数据库在逻辑上是一个独立完整的数据库，但在架构上和物理上采用 多节点分片方式，经过内部算法将数据打散分布来到不同节点存储数据，对前端业务屏蔽后端的复杂架构，并且自身具备数据的最终一致性访问，可用性和分区容灾等特性的数据库。希望本次操作能给大家带来一些对分布式数据库TDSQL的一些认识和收获。
*禁止转载，可转发（转发文章请注明出处）
TDPub企业级分布式关系数据库
F. MySQL、PG属于分布式数据库吗怎么区分数据库是否为分布式
MySQL、PostgreSQL属于关系型数据库
分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
比较火的分布式数据库有tidb和 sequoiadb
G. 数据库架构选型与落地，看这篇就够了
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。
因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。
以下，我从数据库架构、选型与落地来让大家入门。
数据库会面临什么样的挑战呢？
业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。
为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。
将数据库的写操作和读操作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。
这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读操作的场景。
因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；
优点：
缺点：
在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。
优点：
缺点：
在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。
这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。
但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈（单个服务器的IO有上限）。
所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。
优点：
缺点：
四、分库分表
在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。
所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。
分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。
优点：
缺点：
注：分库还是分表核心关键是有没有IO瓶颈 。
分片方式都有什么呢？
RANGE（范围分片）
将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。
比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。
优点：
缺点：
HASH（哈希分片）
将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。
优点：
缺点：
讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。
那么，我们应该如何选择数据库架构呢？
虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。
混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。
1、对事务支持
分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。
2、多库结果集合并 （group by，order by）
由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等操作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。
3、数据延迟
主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。
4、跨库join
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。
5、分片扩容
水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。
6、ID生成
分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。
一、应用层依赖类（JDBC）
这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。
此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等操作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。
中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。
优点
缺点
二、中间层代理类（Proxy）
这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。
所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。
在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是Http协议请求。
比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。
优点
缺点
JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。
Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。
混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。
JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。
向 应用程序完全透明 ，可直接当做MySQL使用。
适用于任何兼容MySQL协议的客户端。
Sharding-JDBC
定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。
以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。
分库（用户）
问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。
拆分维度：企业ID分库
拆分策略：头部企业单独库、非头部企业一个库
分库分表（订单）
问题解析：订单数据增长速度较快，在分库之余需要分表。
拆分维度：企业ID分库、用户ID分表
拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表
单库分表（附件）
问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。
拆分维度：用户ID分表
拆分策略：用户ID取模分表
问题一：分布式事务
分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。
问题二：分布式ID
问题三：跨片查询
举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。
sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。
假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；
特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）
问题四：分片扩容
随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。
假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。
问题五：一致性哈希
首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）
其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。
然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。
所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。
好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。
老规矩，一键三连，日入两千，点赞在看，年薪百万！
本文作者：Jensen
7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。
曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。
技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。
交个朋友，一起成长！
H. mysql如何做成分布式
MySQL做分布式需要通过ndb的Cluster来实现。 MySQLCluster是MySQL适合于分布式计算环境的高实用、高冗余版本。 实现的步骤比较复杂，网络云案例:《MySQLCluster(MySQL集群)分布式》 下载地址:
I. 单机MySQL数据库怎么做成分布式数据库集群
可以采用开源的MyCat解决方案，优点是免费，缺点是出现问题可能要自己解决或者去社区寻找解决方案；
也可以采用北京万里开源软件有限公司的集群解决方案，后端使用开源的MySQL存储数据，优点是有任何问题他们都可以帮忙解决，而且不用担心系统后续的扩展、集群高可用等情况，他们的工程师还开发过MySQL核心代码，找他们可以睡个安稳觉，缺点是不免费，他们还有自己的国产数据库GreatDB，100%兼容MySQL。
对于初创企业，可以考虑选择免费的开源解决方案，毕竟遇到的问题可能有限，如果要想长期稳定发展，还是选择万里开源这样的公司比较靠谱一些。