数据库性能优化

当MySQL单表记录数过大时，数据库的CRUD性能会明显降低，一些常见的优化措施以下：

限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。好比：咱们当用户在查询订单历史的时候，咱们能够控制在一个月的范围内。；

读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；

垂直分区：根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登陆信息又有用户的基本信息，能够将用户表拆分红两个单独的表，甚至放到单独的库作分库。简单来讲垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。

--垂直拆分的优势： 能够使得行数据变小，在查询时减小读取的Block数，减小I/O次数。此外，垂直分区能够简化表的结构，易于维护。

--垂直拆分的缺点： 主键会出现冗余，须要管理冗余列，并会引发Join操做，能够经过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；

水平分区： 保持数据表结构不变，经过某种策略存储数据分片。这样每一片数据分散到不一样的表或者库中，达到了分布式的目的。 水平拆分能够支撑很是大的数据量。 水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时能够把一张的表的数据拆成多张表来存放。举个例子：咱们能够将用户信息表拆分红多个用户信息表，这样就能够避免单一表数据量过大对性能形成影响。水平拆分能够支持很是大的数据量。须要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但因为表的数据仍是在同一台机器上，其实对于提高MySQL并发能力没有什么意义，因此水平拆分最好分库 。水平拆分可以 支持很是大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点Join性能较差，逻辑复杂。《Java工程师修炼之道》的做者推荐 尽可能不要对数据进行分片，由于拆分会带来逻辑、部署、运维的各类复杂度 ，通常的数据表在优化得当的状况下支撑千万如下的数据量是没有太大问题的。若是实在要分片，尽可能选择客户端分片架构，这样能够减小一次和中间件的网络I/O。

 下面补充一下数据库分片的两种常见方案：

客户端代理： 分片逻辑在应用端，封装在jar包中，经过修改或者封装JDBC层来实现。 当当网的Sharding-JDBC 、阿里的TDDL是两种比较经常使用的实现。

中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 咱们如今谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。