MySQL千万级多表关联SQL语句调优

本文不涉及复杂的底层数据结构,通过explain解释SQL,并根据可能出现的情况,来做具体的优化,使千万级表关联查询第一页结果能在2秒内完成(真实业务告警系统优化结果)。

需要优化的查询:使用explain

出现了Using temporary;

有分页时出现了Using filesort则表示使用不了索引,需要根据下面的技巧来调整语句

rows过多,或者几乎是全表的记录数;

key 是 (NULL);

possible_keys 出现过多(待选)索引。

1.使用explain语法,对SQL进行解释,根据其结果进行调优:

MySQL 表关联的算法是 Nest Loop Join,是通过驱动表的结果集作为循环基础数据,然后一条一条地通过该结果集中的数据作为过滤条件到下一个表中查询数据,然后合并结果:

a.EXPLAIN 结果中,第一行出现的表就是驱动表

b.对驱动表可以直接排序,对非驱动表(的字段排序)需要对循环查询的合并结果(临时表)进行排序(Important!),即using temporary;

c. [驱动表] 的定义为:1)指定了联接条件时,满足查询条件的记录行数少的表为[驱动表];2)未指定联接条件时,行数少的表为[驱动表](Important!)。

d.优化的目标是尽可能减少JOIN中Nested Loop的循环次数,以此保证:永远用小结果集驱动大结果集(Important!)!:A JOIN B,A为驱动,A中每一行和B进行循环JOIN,看是否满足条件,所以当A为小结果集时,越快。

e.NestedLoopJoin实际上就是通过驱动表的结果集作为循环基础数据,然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据,然后合并结果。如果还有第三个参与Join,则再通过前两个表的Join结果集作为循环基础数据,再一次通过循环查询条件到第三个表中查询数据,如此往复

2.两表JOIN优化:

a.当无order by条件时,根据实际情况,使用left/right/inner join即可,根据explain优化 ;

b.当有order by条件时,如select * from a inner join b where 1=1 and other condition order by a.col;使用explain解释语句;

1)如果第一行的驱动表为a,则效率会非常高,无需优化;

2)否则,因为只能对驱动表字段直接排序的缘故,会出现using temporary,所以此时需要使用STRAIGHT_JOIN明确a为驱动表,来达到使用a.col上index的优化目的;或者使用left join且Where条件中不含b的过滤条件,此时的结果集为a的全集,而STRAIGHT_JOIN为inner join且使用a作为驱动表

3.多表JOIN优化:

a.无order by条件时,根据实际情况,使用left/right/inner join即可,根据explain优化;

b.有order by a.col条件时,所有join必须为left join,且每个join字段都创建索引,同时where条件中只能有a表的条件,即将其它表的数据关联到a中形成一张大表,再对a的全集进行过滤;

如果不能全使用left join,则需灵活使用STRAIGHT_JOIN及其它技巧,以时间排序为例:

               1)数据入库按照平台时间入库,自然a的数据都按时间有序;

SELECT c.*, r.HYPERVISOR_HOST_NAME hostname, r.HOST_IP FROM trust_monitor c STRAIGHT_JOIN res_node r ON c.res_node_id = r.ID STRAIGHT_JOIN am_assets a ON r.ASSET_ID = a.ID AND a.status = 58 STRAIGHT_JOIN se_role s ON a.DEPT_FLAG = s.ROLE_ORG AND s.ROLE_ID IN (32,33,36,41) where c.STATUS = 58 and c.changed_type = 79 limit 1,10;

SELECT c.*, r.HYPERVISOR_HOST_NAME hostname, r.HOST_IP FROM trust_monitor c inner JOIN res_node r ON c.res_node_id = r.ID INNER JOIN am_assets a ON r.ASSET_ID = a.ID AND a.status = 58 INNER JOIN se_role s ON a.DEPT_FLAG = s.ROLE_ORG AND s.ROLE_ID IN (32,33,36,41) where c.STATUS = 58 and c.changed_type = 79 order by c.changed_time limit 1,10;

两者结果一致

4.误区:

a.视图只是屏蔽或者高效集合多表数据的一种方法,视图与表JOIN,不会起到任何效果

参考:

http://www.cnblogs.com/zhengyun_ustc/p/slowquery1.html

http://huoding.com/2013/06/04/261

http://www.cnblogs.com/uttu/p/6384541.html

原文地址:https://www.cnblogs.com/jpfss/p/9167145.html

时间: 2024-10-15 22:24:50

MySQL千万级多表关联SQL语句调优的相关文章

MYSQL千万级数据表,创建表及字段扩展的几条建议

MYSQL千万级数据表,创建表及字段扩展的几条建议 一:概述 当我们设计一个系统时,需要考虑到系统的运行一段时间后,表里数据量大约有多少,如果在初期,就能估算到某几张表数据量非常庞大时(比如聊天消息表),就要把表创建好,这篇文章从创建表,增加数据,以及字段扩展,这几个方面来给出建议. 二:创建表 假如现在我们需要创建IM项目中的聊天消息表,这个表数据量大,读操作远超过写操作,我们都知道,mysql常用的数据库引擎主要有innodb,myisam,这两个数据库引擎主要区别是,innodb支持事务,

Mysql千万级大表优化

Mysql的单张表的最大数据存储量尚没有定论,一般情况下mysql单表记录超过千万以后性能会变得很差.因此,总结一些相关的Mysql千万级大表的优化策略. 1.优化sql以及索引 1.1优化sql 1.有索引但未被用到的情况(不建议) (1)避免like的参数以通配符开头时 尽量避免Like的参数以通配符开头,否则数据库引擎会放弃使用索引而进行全表扫描. 以通配符开头的sql语句,例如:select * from t_credit_detail where Flistid like '%0'\G

mysql数据库sql语句调优 、

mysql数据库sql语句调优 . 索引设计原则: 索引列一般为where子句中的列或连接字句中的列 尽量不对基数小的列做索引,如性别列 尽可能使用短索引:如果对字符列索引尽量指定最小长度. (short Keys are better,Integer best) create index cityname on city(city(10)); 复合索引前缀特性,索引的顺序很重要. key(a,b,c)联合索引: 可以走索引的组合:key(a),key(a,b ),key(a,b,c) 下列索引

【优化】MySQL千万级大表优化解决方案

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

SQL语句调优

sql语句优化原则 性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几

SQL语句调优三板斧

改装有顺序------常开的爱车下手 你的系统中有成千上万的语句,那么优化语句从何入手呢 ? 当然是系统中运行最频繁,最核心的语句了.废话不多说,上例子: 这是一天的语句执行情况,里面柱状图表示的是对应执行时间段内语句的次数,总体看起来长时间语句非常多. 下面看一下具体的语句执行情况: 排位第一的语句执行次数38508次,是一个存储过程(RPC:Completed 表示存储过程结束,不知道这个的请看profiler的使用说明).其中的一条语句(SP:StmtCompleted)也就是排在第二位的

Mysql千万级大表同步复制的一些问题

1 [[email protected] ~]# pt-online-schema-change -u root -p xxxxxx -h localhost -A utf8 D=jinyuanbao,t=DistributionGoods --new-table-name DistributionGoods_0 --no-drop-trigger --no-swap-table --no-drop-new-table --execute 2 No slaves found. See --rec

SQL 语句调优 where 条件 数据类型 临时表 索引

基本原则 避免全表扫描 建立索引 尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理 尽量避免大事务操作,提高系统并发能力 使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效.尽量避免使用游标,因为游标的效率较差. where 后的条件 应尽量避免在 where 子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描. 应尽量避免在 where 子句中使用 or 来连接条件,可以考虑使用union 代替 in 和

MYSQL一次千万级连表查询优化

概述:交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的功能,这算是离职人员挖下的坑,随着数据越来越多,原本的SQL查询变得越来越慢,用户体验特别差,因此SQL优化任务交到了我手上. 这个SQL查询关联两个数据表,一个是攻击IP用户表主要是记录IP的信息,如第一次攻击时间,地址,IP等等,一个是IP攻击次数表主要是记录每天IP攻击次数.而需求是获取某天攻击IP信息和次数.(以下SQL语句测试均在测试服务器上上,正式服务器的性能好,查询时间快不少.) 准备:查看表的行数: 未优化前SQL