当 MySQL 单表记录数过大时，数据库的 CRUD 性能会明显下降，一些常见的优化措施如下：
-
限定范围： 务必禁止不带任何限制数据范围条件的查询语句，比如：当用户在查询订单历史的时候，可以控制在一个月的范围内；
-
读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；
-
垂直分区： 根据数据库里面数据表的相关性进行拆分。例如，用户表中既有用户的登录信息，又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。简单来说，垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。 如下图所示：
垂直分区
垂直拆分的优点： 可以使行数据变小，在查询时减少读取的 Block 数，减少 I/O 次数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起 Join 操作，可以通过在应用层进行 Join 来解决。此外，垂直分区会让事务变得更加复杂；
- 水平分区： 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据就分散到不同的表或者库中，达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。举个例子：可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。
水平拆分
水平拆分可以支持非常大的数据量。需要注意的一点是：分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升 MySQL 并发能力没有什么意义，所以 水平拆分最好分库 。水平拆分能够 支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点 Join 性能较差，逻辑复杂。《Java 工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的数据表在优化得当的情况下，支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络 I/O。
下面补充一下数据库分片的两种常见方案：
- 客户端代理： 分片逻辑在应用端，封装在 Jar 包中，通过修改或者封装 JDBC 层来实现。 当当网的 Sharding-JDBC 、阿里的 TDDL 是两种比较常用的实现。
- 中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的 Atlas、网易的 DDB 等等都是这种架构的实现。
网友评论