
mysql数据库中,数据量很大的表,有什么优化方案
小我私人的看法,这种大表的优化,纷歧定上来就要分库分表,由于表一旦被拆分,开发、运维的庞大度会直线上升,而大多数公司是欠缺这种能力的。以是MySQL中几百万甚至小几万万的表,先思量做单表的优化。
单表优化单表优化可以从这几个角度出发:
表分区:MySQL在5.1之后才有的,可以看做是水平拆分,分区表需要在建表的需要加上分区参数,用户需要在建表的时刻加上分区参数;分区表底层由多个物理子表组成,然则对于代码来说,分区表是透明的;SQL中的条件中最好能带上分区条件的列,这样可以定位到少量的分区上,否则就会扫描所有分区。
读写星散:最常用的优化手段,写主库读从库;
增添缓存:主要的头脑就是削减对数据库的接见,缓存可以在整个架构中的许多地方,好比:数据库自己有就缓存,客户端缓存,数据库接见层对SQL语句的缓存,应用程序内的缓存,第三方缓存(如Redis等);
字段设计:单表不要有太多字段;VARCHAR的长度只管只分配真正需要的空间;只管使用TIMESTAMP而非DATETIME;阻止使用NULL,可以通过设置默认值解决。
索引优化:索引不是越多越好,针对性地确定索引,索引会加速查询,然则对新增、修改、删除会造成一定的影响;值域很少的字段不适合建索引;只管不用UNIQUE,不要设置外键,由程序保证;
SQL优化:只管使用索引,也要保证不要由于错误的写法导致索引失效;好比:阻止前导模糊查询,阻止隐式转换,阻止等号左边做函数运算,in中的元素不宜过多等等;
NoSQL:有一些场景,可以甩掉MySQL等关系型数据库,拥抱NoSQL;好比:统计类、日志类、弱结构化的数据;事务要求低的场景。
表拆分数据量进一步增大的时刻,就不得不思量表拆分的问题了:
垂直拆分:垂直拆分的意思就是把一个字段较多的表,拆分成多个字段较少的表;上文中也说过单表的字段不宜过多,若是初期的表结构设计的就很好,就不会有垂直拆分的问题了;一样平常来说,MySQL单表的字段最好不要跨越二三十个。
水平拆分:就是我们常说的分库分表了;分表,解决了单表数据过大的问题,然则事实还在统一台数据库服务器上,以是IO、CPU、网络方面的压力,并不会获得彻底的缓解,这个可以通太过库来解决。水平拆分优点很显著,可以使用多台数据库服务器的资源,提高了系统的负载能力;瑕玷是逻辑会变得庞大,跨节点的数据关联性能差,维护难度大(稀奇是扩容的时刻)。
希望我的回覆,能够辅助到你!我将连续分享Java开发、架构设计、程序员职业生长等方面的看法,希望能获得你的关注。
本文部分内容来源于互联网,如有侵权请联系我们删除!外链是什么?增加外链的方法有哪些?