mysql数据库中，数据量很大的表，有什么优化方案

小我私人的看法，这种大表的优化，纷歧定上来就要分库分表，由于表一旦被拆分，开发、运维的庞大度会直线上升，而大多数公司是欠缺这种能力的。以是MySQL中几百万甚至小几万万的表，先思量做单表的优化。

单表优化单表优化可以从这几个角度出发：

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

读写星散：最常用的优化手段，写主库读从库；

增添缓存：主要的头脑就是削减对数据库的接见，缓存可以在整个架构中的许多地方，好比：数据库自己有就缓存，客户端缓存，数据库接见层对SQL语句的缓存，应用程序内的缓存，第三方缓存（如Redis等）；

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

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

SQL优化：只管使用索引，也要保证不要由于错误的写法导致索引失效；好比：阻止前导模糊查询，阻止隐式转换，阻止等号左边做函数运算，in中的元素不宜过多等等；

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

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

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

水平拆分：就是我们常说的分库分表了；分表，解决了单表数据过大的问题，然则事实还在统一台数据库服务器上，以是IO、CPU、网络方面的压力，并不会获得彻底的缓解，这个可以通太过库来解决。水平拆分优点很显著，可以使用多台数据库服务器的资源，提高了系统的负载能力；瑕玷是逻辑会变得庞大，跨节点的数据关联性能差，维护难度大（稀奇是扩容的时刻）。

希望我的回覆，能够辅助到你！我将连续分享Java开发、架构设计、程序员职业生长等方面的看法，希望能获得你的关注。

外链是什么？增加外链的方法有哪些？

本文部分内容来源于互联网，如有侵权请联系我们删除！