到底什么时候要分库分表？

http://shardingsphere.apache.org/index_zh.html

本质上：分布式的数据中间件--解决方案；

https://shardingsphere.apache.org/document/current/cn/overview/快速指南：

主要的事两个东西：

shardingsphere-JDBC 轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。

它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

shardingSphere -proxy:透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持

为什么会出现这个数据库中间件的软件：shardingSphere 的数据库中间件

   在电商环境中，我们一般是对于数据量是在逐步提升的一个状态，在数据库中的量级达到百万级别或者是千万级别之后，数据库中的基本操作CRUD是比较耗费时间的，可能会导致用户体验降低， 虽然我们可以通过 ： ①sql优化 ②索引优化 ③分库分表

复制代码

当然我们也可以从硬件上提高服务器的存储水平和处理业务的效率，增加硬盘的存储空间和增加内存等，但是这些都是暂时可以提供一些便利；

比如十年前的 jd:数据库的 db 设计:

表示的是简单 dB 中，可以将数据单表的 mysql 中的数据表，单表的存储量

随时物流，网络时代，和个人消费水平的提高，电商平台买东西已经是家常便饭，但是这样的话，要求平台数据性能在快的同时，也对数据库的效率提出了更高的要求，比如数据要分库分表，所谓分库：

注意事项：

我们这里显示的事主要的对比结果；

mysql 的单表保持在多少比较合适，前百度 DBA 中流传出来的，当 mysql 表中的单表的数据量达到 2000 万行时，sql 的性能直线下降不久前，阿里提出的开发手册中提到单表数据超过 500 万行或者单表的容量超过 2G，考虑分库分表；，显然我们没法测试具体的 mysql 的数据表瓶颈，理论上是 T 级别的，但是可能会随着操作系统的文件的管控而变化；阿里铁律造就额这个数据；

3.sql 的编写需要注意优化

• 使用 limit 对查询结果的记录进行限定
• 避免 select *，将需要查找的字段列出来
• 使用连接（join）来代替子查询
• 拆分大的 delete 或 insert 语句
• 可通过开启慢查询日志来找出较慢的 SQL
• 不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边
• sql 语句尽可能简单：一条 sql 只能在一个 cpu 运算；大语句拆小语句，减少锁时间；一条大 sql 可以堵死整个库
• OR 改写成 IN：OR 的效率是 n 级别，IN 的效率是 log(n)级别，in 的个数建议控制在 200 以内
• 不用函数和触发器，在应用程序实现
• 避免 %xxx 式查询
• 少用 JOIN
• 使用同类型进行比较，比如用'123'和'123'比，123 和 123 比
• 尽量避免在 WHERE 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
• 对于连续数值，使用 BETWEEN 不用 IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
• 列表数据不要拿全表，要使用 LIMIT 来分页，每页数量也不要太大

这时候我们需要的的 sharding sphere 的数据库中间件就大有用处了

4.垂直分表：

将一个表中经过逻辑拆分成两个表一个存放具体的基本信息，用于列表展示，一个存放特殊描述信息，用于点击之后具体的课程信息；

这就有很多好处，如果说我们需要改变课程描述的信息，但是在未垂直分表之前，我们将数据是其他课程基本信息不能动的，但是现在是分表之后基本信息不影响；

单数据库多表的操作会使得性能耗费巨大，io 增多；

5.垂直分库：

把具体的业务划分出具体的数据库，形成专表专库的形式；

水平分库：单表数据量大，单表中也不能进行数据字段的格式垂直切分；

垂直改变的事数据的结构， 表的结构分开，业务系统的专用数据库

水平对于的是表中的数据来操作， 分流数据，分为多个库，库中在细分

总结：

对于业务系统的垂直和水平的分层，可以更好的整理库中的字段关系，为高并发下的生成数据打下基础