千万级的大表!MySQL这样优化更好

对于一个千万级的大表,现在可能更多的是亿级数据量,很多人第一反应是各种切分,可结果总是事半功倍,或许正是我们优化顺序的不正确。下面我们来谈谈怎样的优化顺序可以让效果更好。

MySQL数据库一般都是按照下面的步骤去演化,成本也是由低到高:

1/ SQL优化

1. 避免使用select *

  • 返回结果过多,降低查询的速度;
  • 过多的返回结果,增加数据传输量;

2. 可确定返回记录数的,尽量增加limit n;

3. 尽量少用like查询,会导致索引失效;

2/ 软件优化

1. 选择合理的引擎

  • MyISAM索引顺序访问方法,支持全文索引,非事务安全,不支持外键,会加表级锁;
  • InnoDB事务型存储引擎,加行锁,支持回滚,崩溃恢复,ACID事务控制;

2. 正确使用索引

  • 结合适的列表建立索引;
  • 索引值应该不相同,唯一值时效果最好,大量重复效果很差;
  • 不能滥用索引,索引占用空间;
  • 使用短索引,存的索引多,消耗IO更小,能提高查找速度;

3. 字段尽量设置成NOT NULL

  • NULL占空间,对于Java和OC强类型的,容易千万APP闪退;

4. MySQL分区表

3/ 硬件优化

1. Linux内核用内存开缓存存储数据;

2. 增加应用缓存,例如Memcached、Redis读写性能非常高;

3. 用SSD代替机械硬盘

  • 日志和数据分开存储,日志顺序读写 - 机械硬盘,数据随机读写 - SSD;

4. SSD+SATA混合存储,对热数据缓存,例如:FlashCache;

4/ 架构优化

1. 读写分离

  • 可以把数据库读和写拆开,对应主从服务器,主服务器写操作、从服务器是读操作;
  • 读是一些机器,写是一些机器,二进制文件的主从复制,延迟解决方案;
  • 主服务器写操作的同时,同步到从服务器,保持数据完整性——主从复制;

2. 垂直拆分

  • 根据模块的耦合度,将一个大的系统分为多个小的系统,也就是分布式系统;
  • 字段分成多个表;

3. 水平拆分

  • 分表:数据分成多个表,拆分后的每张表的表头相同;
  • 分库:类型方案有Cobar(阿里开源,无更新)、MyCat(基于Cobar);

总结

尽我们所能去优化SQL吧!它成本最低,却又是一项费时费力的活,需要在技术与业务都熟悉的情况下,用心去优化才能做到最优,优化后效果也是立竿见影的!

原文地址:https://www.cnblogs.com/tiancai/p/9036413.html

时间: 2024-11-26 06:54:15

千万级的大表!MySQL这样优化更好的相关文章

MySQL 对于千万级的大表要怎么优化?

https://www.zhihu.com/question/19719997 千万级,MySQL实际上确实不是什么压力,InnoDB的存储引擎,使用的是B+树存储结构,千万级的数据量,基本也就是三到四层的搜索,如果有合适的索引,性能基本也不是问题. 但经常出现的情况是,业务上面的增长,导致数据量还会继续增长,为了应对这方面的问题而必须要做扩展了此时可能首先需要考虑的就是分表策略了. 当然分表,可能还有其它几个原因,比如表变大了,千万级的数据库,为了减少运维成本,降低风险,就想到了通过分表来解决

MySQL 对于千万级的大表要怎么优化

转自知乎 作者:哈哈链接:http://www.zhihu.com/question/19719997/answer/81930332来源:知乎著作权归作者所有,转载请联系作者获得授权. 很多人第一反应是各种切分:我给的顺序是:第一优化你的sql和索引: 第二加缓存,memcached,redis: 第三以上都做了后,还是慢,就做主从复制或主主复制,读写分离,可以在应用层做,效率高,也可以用三方工具,第三方工具推荐360的atlas,其它的要么效率不高,要么没人维护: 第四如果以上都做了还是慢,

Mysql千万级记录表分表策略

目前,比较流行的分表为2倍扩容. 表A(id, name, age, sex) 基于自增id分表, 通过触发器先同步A到B, 程序通过mod 2操作数据,然后drop掉触发器,在 删除两个A表的偶数id, B表的奇数id.在alter table A engine=InnoDB;去除索引碎片.依次类推2个表分解成四个表,四个变8个表.. 这样,大表的负载降低提高表的利用率. (表聚合待续)

记录一次MySQL两千万数据的大表优化解决过程,提供三种解决方案

问题概述 使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务. 问题前提:老系统,当时设计系统的人大概是大学没毕业,表设计和sql语句写的不仅仅是垃圾,简直无法直视.原开发人员都已离职,到我来维护,这就是传说中的维护不了就跑路,然后我就是掉坑的那个!!! 我尝试解决该问题,so,有个这个日志. 方案概述 方案一:优化现有mysql数据库.优点:不影响现有业务

mysql大表更新sql的优化策略(转)

看了该文章之后,很受启发,mysql在update时,一般也是先select,而此时,如果没有使用索引,那会锁住整个表.使用索引的最佳 方式是使用主键,如果我们知道主键的范围(只要是精确范围的超集就可以了),那可以在查询条件中加上主键的范围,这样查询时,会 使用主键索引,就可以提高查询的速度了.这样,我们不用单独再给其它字段加索引,使用已知的索引就可以加速查询,这种方式感觉很屌. 原文:http://blog.csdn.net/bruce128/article/details/17426671

MySQL 对于大表(千万级),要怎么优化呢?

提问:如何设计或优化千万级别的大表?此外无其他信息,个人觉得这个话题有点范,就只好简单说下该如何做,对于一个存储设计,必须考虑业务特点,收集的信息如下:1.数据的容量:1-3年内会大概多少条数据,每条数据大概多少字节: 2.数据项:是否有大字段,那些字段的值是否经常被更新: 3.数据查询SQL条件:哪些数据项的列名称经常出现在WHERE.GROUP BY.ORDER BY子句中等: 4.数据更新类SQL条件:有多少列经常出现UPDATE或DELETE 的WHERE子句中: 5.SQL量的统计比,

Mysql limit 优化,百万至千万级快速分页,--复合索引的引用并应用于轻量级框架

MySql 性能到底能有多高?用了php半年多,真正如此深入的去思考这个问题还是从前天开始.有过痛苦有过绝望,到现在充满信心!MySql 这个数据库绝对是适合dba级的高手去玩的,一般做一点1万篇新闻的小型系统怎么写都可以,用xx框架可以实现快速开发.可是数据量到了10万,百万至千 万,他的性能还能那么高吗?一点小小的失误,可能造成整个系统的改写,甚至更本系统无法正常运行!好了,不那么多废话了.用事实说话,看例子: 数据表 collect ( id, title ,info ,vtype) 就这

php+Mysql 优化,百万至千万级快速分页

php+Mysql 优化,百万至千万级快速分页 MySql 性能到底能有多高?用了php半年多,真正如此深入的去思考这个问题还是从前天开始.有过痛苦有过绝望,到现在充满信心!MySql 这个数据库绝对是适合dba级的高手去玩的,一般做一点1万篇新闻的小型系统怎么写都可以,用xx框架可以实现快速开发.可是数据量到了10万,百万至千万,他的性能还能那么高吗?一点小小的失误,可能造成整个系统的改写,甚至更本系统无法正常运行!好了,不那么多废话了.用事实说话,看例子: 数据表 collect ( id,

Mysql大表查询优化技巧总结及案例分析

http://www.169it.com/article/3219955334.html sql语句使用基本原则:1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引.2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id... sql语句使用基本原则: 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2