到底什么时候要分库分表？
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 的数据库中间件
当然我们也可以从硬件上提高服务器的存储水平和处理业务的效率，增加硬盘的存储空间和增加内存等，但是这些都是暂时可以提供一些便利；
比如十年前的 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.垂直分库：
把具体的业务划分出具体的数据库，形成专表专库的形式；
水平分库：单表数据量大，单表中也不能进行数据字段的格式垂直切分；
垂直改变的事数据的结构， 表的结构分开，业务系统的专用数据库
水平对于的是表中的数据来操作， 分流数据，分为多个库，库中在细分
总结：
对于业务系统的垂直和水平的分层，可以更好的整理库中的字段关系，为高并发下的生成数据打下基础
版权声明: 本文为 InfoQ 作者【卢卡多多】的原创文章。
原文链接:【http://xie.infoq.cn/article/df2c1e232d7dd2e1b56f469bb】。文章转载请联系作者。
努力寻找生活答案的旅途者 2020.04.12 加入
公众号：卢卡多多，欢迎一起交流学习
评论 (1 条评论)