mysql用户表优化_大表优化

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

****

1. 限定数据的范围：务必禁止不带任务限制数据范围条件的查询语句。比如：我们当用户再查询订单历史的时候，我们可以控制再一个月的范围内

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

3. 垂直分区：根据数据里的数据表的相关性进行拆分。例如，用户表中既有用户的登陆信息又有用户基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分多张表：


* 垂直拆分的优点：可以使得列数据变小，在查询时，减少读取的block次数，减少I/O次数。此外，垂直区分可以简化表的结构，易于维护

* 垂直拆分的缺点：主键会出现冗余，需要管理冗余列，并会引起join操作

4. 水平分区：保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。水平拆分可以支撑非常大的数据量。水平拆分是指数据表行的拆分，表的行数超过200W行时，就会变慢，这时可以把一张表的数据拆成多张表来存放。举个例子：我们可以讲用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响


水平拆分可以支持非常大的数据量。需要注意的一点是：分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是再同一台机器上，其实对于提升mysql并发能力并没有什么意义，所以**水平拆分最好分库**

水平拆分能够支持非常大的数据量存储，应用端改造也少，但是分片事务难以解决，跨节点join性能较差，逻辑复杂。所以尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度，一般的数据库在优化得当的情况下，支撑千万以下的数据量是没有太大的问题。如果实在要分片，尽量选择客户端分片架构，这样可以节能少一次和中间件的网络i/o

**数据库分片的两种常见方案：**

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

* 中间件代理：在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。Mycat,360的Atlas，网易的DDB