MySQL数据库中，数据量越来越大，有什么具体的优化方案么？

个人的观点，这种大表的优化，不一定上来就要分库分表，因为表一旦被拆分，开发、运维的复杂度会直线上升，而大多数公司和开发人员是欠缺这种能力的。
所以 MySQL 中几百万甚至小几千万的表，先考虑做单表的优化。

单表优化

1.表分区

MySQL 在 5.1 之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；
分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的；
SQL 中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。

2.增加缓存

主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方；
比如：数据库本身有就缓存，客户端缓存，数据库访问层对 SQL 语句的缓存，应用程序内的缓存，第三方缓存（如 Redis
等）；

3.字段设计

• 单表不要有太多字段；
• VARCHAR 的长度尽量只分配真正需要的空间；
• 尽量使用 TIMESTAMP 而非 DATETIME；
• 避免使用 NULL ，可以通过设置默认值解决。

MySQL数据库中，数据量越来越大，有什么具体的优化方案么？

MySQL数据库中，数据量越来越大，有什么具体的优化方案么？

4.索引优化

• 索引不是越多越好，针对性地建立索引，索引会加速查询，但是对新增、修改、删除会造成一定的影响；
• 值域很少的字段不适合建索引；
• 尽量不用 UNIQUE，不要设置外键，由程序保证；

5.索引优化

尽量使用索引，也要保证不要因为错误的写法导致索引失效；
比如：避免前导模糊查询，避免隐式转换，避免等号左边做函数运算，in 中的元素不宜过多等等；

6.NoSQL

有一些场景，可以抛弃 MySQL 等关系型数据库，拥抱 NoSQL；
比如：统计类、日志类、弱结构化的数据；事务要求低的场景。

[图片上传中...(image-24aa9c-1575007399050-1)]

表拆分

数据量进一步增大的时候，就不得不考虑表拆分的问题了：

1.垂直拆分

垂直拆分的意思就是把一个字段较多的表，拆分成多个字段较少的表；上文中也说过单表的字段不宜过多，如果初期的表结构设计的就很好，就不会有垂直拆分的问题了；一般来说，MySQL 单表的字段最好不要超过二三十个。

2.水平拆分

就是我们常说的分库分表了；分表，解决了单表数据过大的问题，但是毕竟还在同一台数据库服务器上，所以 IO、CPU、网络方面的压力，并不会得到彻底的缓解，这个可以通过分库来解决。
水平拆分优点很明显，可以利用多台数据库服务器的资源，提高了系统的负载能力；缺点是逻辑会变得复杂，跨节点的数据关联性能差，维护难度大（特别是扩容的时候）。

会点代码的大叔 | 【原创】

---

image.png