一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句
1，slow_query_log
这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。
2，long_query_time
当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
3，slow_query_log_file
记录日志的文件名。
4，log_queries_not_using_indexes
这个参数设置为ON，可以捕获到所有未使用索引的SQL语句，尽管这个SQL语句有可能执行得挺快。
二、检测mysql中sql语句的效率的方法
1、通过查询日志
（1）、Windows下开启MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上
代码如下
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
long_query_time = 2
（2）、Linux下启用MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上
代码如下
log-slow-queries=/data/mysqldata/slowquery。log
long_query_time=2
B. mysql 优化sql方法有哪些
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
6.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
C. mysql 存储过程执行太慢怎么优化
1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断
2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。
3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析
4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.
5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...
6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化
7.查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行?它是先执行username = toby还是password = 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.
8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1
9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)
10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。
D. mysql的sql语句优化5种方式
只有5种吗？我知道十种以上的说。
索引（没我得全表查询了）
改变数据储引擎（MyISAM没事务再也不用担心锁表了）
增加冗余数来减少连表查询数（消耗硬盘空间减少CPU使用）
调整查询顺序减少查询量优先（数量少了连表的笛卡儿积也少了）
全文索引（文字长度有限制，而且IO使用量会大增，但是妥妥的快）
查询尽量不要用函数（函数可是不走索引的哦亲）
查询变量类型要提前对好减少系统负担（我提前改变了系统你就不用检测了）
升级服务器硬件（没什么是氪金解决不了的）
配置好临时表空间，合理理由临时表减少主表查询抢资源（唯我独查）
合理理由函数减少系统的判断（明明都能确认内容不同你用UNION 系统还是傻傻的查一遍是否重复UNION ALL则跳过这个步骤同理 inner join 和 left join 也一样）
强制走索引（复合索引的情况有时候手动走比系统判断要好哦）
脏读、幻读等（你堵车我绕路）
数据归档，迁移（没用的数据要进仓哦，别占着主表的资源）
表的碎片整理（迁移后碎片整理更健康哦亲）
索引重构（数据都走了索引也应该重构一下才能保证速度哦）
善用存储过程（串N个表（N大于10）的查询千万别一个SQL到底，分布式查询在吧结果集合并吧骚年）
预处理数据（mysql也有job哦，对于经常要子查询的数据可以先弄个明细表根据主表在后台进行补完，查询的时候就更方便了）
懒得说了。。。。。。。。。。。。。。。。。。
E. 关于优化mysql中的sql语句
character introcer翻译过来就是字符引导。也就是针对字符串，显式的给定一个字符编码和排序规则，不受系统参数的影响。
总结 Introcer 使用规则：
1. convert 函数
convert 函数类似于 introcer，不过只能指定字符集。
2. charset 函数
检测字符串的字符集。可以检测出当前字符串在当前 session 的字符集。
3. set names 语句
语法为：
SETNAMES{'charset_name'[COLLATE 'collation_name'] | DEFAULT}
这条语句最常用，可是也最容易被滥用，比如语句：
set names latin1 collate latin1_bin;
执行后会默认执行一系列语句，也就是把非服务端的相关参数给重新设定了。
SET{CHARACTERSET|CHARSET}{'charset_name' | DEFAULT}
类似语句 set names，同样是设置以下三个 session 参数：
character_set_results
character_set_client
character_set_connection
4. set character set 语句语法为：
同样是可以恢复默认值，还有同样的限制规则等。不过有两点不同：1）参数 character_set_connection 的值不会被设定为指定的字符集，而是继承参数 character_set_database 所设定的字符集。
5. collate 子句
collate 语句强制指定排序规则，优先级最高。也就是显式指定 collate 会覆盖已有的排序规则。
这里涉及到单个字符串以及字符串拼接的排序规则问题。
F. MySQL——SQL优化
优化的目的就是让sql语句使用索引，避免进行全文检索，以此加速检索的速度。在使用mysql的过程中，我们接触最多的就是sql语句了。这是最容易优化也是最常优化的地方。
SQL优化有以下几点：
explain模拟优化器执行SQL语句，在5.6以及以后的版本中，除过select，其他比如insert，update和delete均可以使用explain查看执行计划，从而知道mysql是如何处理sql语句，分析查询语句或者表结构的性能瓶颈。
explain的作用
G. mysql SQL语句优化
语句基本上没什么可优化的，最多就是查询条件的引号要取消，例如：
select * from aa where 编号=指定编号
你的主索引，是PRIMARY KEY吧，唯一、非空，这已经是最高级别的索引了，数据库也没有再次优化的余地
剩下可做的事情就是数据库系统优化，例如改变索引缓冲区长度(key_buffer)
一般，该变量控制缓冲区的长度在处理索引表（读/写操作）时使用。MySQL使用手册指出该变量可以不断增加以确保索引表的最佳性能，并推荐使用与系统内存25％的大小作为该变量的值。这是MySQL十分重要的配置变量之一，如果你对优化和提高系统性能有兴趣，可以从改变 key_buffer_size变量的值开始。
如果MYISAM引擎，可以考虑使用myisamchk -r进行修复，例如：
myisamchk --sort_buffer_size=16M --key_buffer_size=16M --read_buffer_size=1M --write_buffer_size=1M -r aa
H. Mysql SQL优化之 limit offset 很大时性能降低
Mysql SQL优化之 limit offset 很大时性能降低(InnoDB引擎)
在 mysql 中,如果select时 offset 很大, 即使相关索引建的挺好, 也会悔闭造成慢查询.
如:
索引只能找到主键,要取其他字段,还要用主键逐个查表,判断条件并排序,然后抛弃 offset 个, 留下 offset+1 到 offset+limit 个. 时间被花在了用主键逐个查表取别的字段那庆返里了誉前饥.
如果能在找主键的时候就抛弃不需要的行,然后需要其他字段的时候再按主键取,就能避免逐条按主键取其他字段的 IO 时间, 从而提高性能.
https://www.jb51.net/article/141933.htm
I. MySQL中如何查看“慢查询”，如何分析执行SQL的效率
一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句x0dx0ax0dx0a1，slow_query_logx0dx0a这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。x0dx0ax0dx0a2，long_query_timex0dx0a当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。x0dx0ax0dx0a3，slow_query_log_filex0dx0a记录日志的文件名。x0dx0ax0dx0a4，log_queries_not_using_indexesx0dx0a这个参数设置为ON，可以捕获到所有未使用索引的SQL语句，尽管这个SQL语句有可能执行得挺快。x0dx0ax0dx0a二、检测mysql中sql语句的效率的方法x0dx0ax0dx0a1、通过查询日志x0dx0a（1）、Windows下开启MySQL慢查询x0dx0aMySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上x0dx0a代码如下x0dx0alog-slow-queries = F:/MySQL/log/mysqlslowquery。logx0dx0along_query_time = 2x0dx0ax0dx0a（2）、Linux下启用MySQL慢查询x0dx0aMySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上x0dx0a代码如下x0dx0alog-slow-queries=/data/mysqldata/slowquery。logx0dx0along_query_time=2x0dx0a说明x0dx0alog-slow-queries = F:/MySQL/log/mysqlslowquery。x0dx0a为慢查询日志存放的位置，一般这个目录要有MySQL的运行帐号的可写权限，一般都将这个目录设置为MySQL的数据存放目录；x0dx0along_query_time=2中的2表示查询超过两秒才记录；x0dx0ax0dx0a2.show processlist 命令x0dx0ax0dx0aSHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。x0dx0a各列的含义和用途：x0dx0aID列x0dx0a一个标识，你要kill一个语句的时候很有用，用命令杀掉此查询 /*/mysqladmin kill 进程号。x0dx0auser列x0dx0a显示单前用户，如果不是root，这个命令就只显示你权限范围内的sql语句。x0dx0ahost列x0dx0a显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。x0dx0adb列x0dx0a显示这个进程目前连接的是哪个数据库。x0dx0acommand列x0dx0a显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。x0dx0atime列x0dx0a此这个状态持续的时间，单位是秒。x0dx0astate列x0dx0a显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个 sql语句，以查询为例，可能需要经过ing to tmp table，Sorting result，Sending data等状态才可以完成x0dx0ainfo列x0dx0a显示这个sql语句，因为长度有限，所以长的sql语句就显示不全，但是一个判断问题语句的重要依据。x0dx0ax0dx0a这个命令中最关键的就是state列，mysql列出的状态主要有以下几种：x0dx0aChecking tablex0dx0a正在检查数据表（这是自动的）。x0dx0aClosing tablesx0dx0a正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。x0dx0aConnect Outx0dx0a复制从服务器正在连接主服务器。x0dx0ax0dx0aCopying to tmp table on diskx0dx0a由于临时结果集大于tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存。x0dx0aCreating tmp tablex0dx0a正在创建临时表以存放部分查询结果。x0dx0adeleting from main tablex0dx0a服务器正在执行多表删除中的第一部分，刚删除第一个表。x0dx0adeleting from reference tablesx0dx0a服务器正在执行多表删除中的第二部分，正在删除其他表的记录。x0dx0ax0dx0aFlushing tablesx0dx0a正在执行FLUSH TABLES，等待其他线程关闭数据表。x0dx0aKilledx0dx0a发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效。x0dx0aLockedx0dx0a被其他查询锁住了。x0dx0aSending datax0dx0a正在处理SELECT查询的记录，同时正在把结果发送给客户端。x0dx0ax0dx0aSorting for groupx0dx0a正在为GROUP BY做排序。x0dx0aSorting for orderx0dx0a正在为ORDER BY做排序。x0dx0aOpening tablesx0dx0a这个过程应该会很快，除非受到其他因素的干扰。例如，在执ALTER TABLE或LOCK TABLE语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。x0dx0aRemoving plicatesx0dx0a正在执行一个SELECT DISTINCT方式的查询，但是MySQL无法在前一个阶段优化掉那些重复的记录。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端。x0dx0ax0dx0aReopen tablex0dx0a获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。x0dx0aRepair by sortingx0dx0a修复指令正在排序以创建索引。x0dx0aRepair with keycachex0dx0a修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。x0dx0aSearching rows for updatex0dx0a正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。x0dx0aSleepingx0dx0a正在等待客户端发送新请求.x0dx0ax0dx0aSystem lockx0dx0a正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表，那么可以通过增加--skip-external-locking参数来禁止外部系统锁。x0dx0aUpgrading lockx0dx0aINSERT DELAYED正在尝试取得一个锁表以插入新记录。x0dx0aUpdatingx0dx0a正在搜索匹配的记录，并且修改它们。x0dx0ax0dx0aUser Lockx0dx0a正在等待GET_LOCK()。x0dx0aWaiting for tablesx0dx0a该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。x0dx0awaiting for handler insertx0dx0aINSERT DELAYED已经处理完了所有待处理的插入操作，正在等待新的请求。x0dx0a大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了，需要检查一下。x0dx0a还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着。x0dx0ax0dx0a例如如图：x0dx0ax0dx0a3、explain来了解SQL执行的状态x0dx0aexplain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。x0dx0a使用方法，在select语句前加上explain就可以了：x0dx0a例如：x0dx0aexplain select surname,first_name form a,b where a.id=b.idx0dx0a结果如图x0dx0ax0dx0aEXPLAIN列的解释x0dx0atablex0dx0a显示这一行的数据是关于哪张表的x0dx0atypex0dx0a这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALLx0dx0apossible_keysx0dx0a显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句x0dx0akeyx0dx0a实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句 中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引x0dx0akey_lenx0dx0a使用的索引的长度。在不损失精确性的情况下，长度越短越好x0dx0arefx0dx0a显示索引的哪一列被使用了，如果可能的话，是一个常数x0dx0arowsx0dx0aMYSQL认为必须检查的用来返回请求数据的行数x0dx0aExtrax0dx0a关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢x0dx0ax0dx0aextra列返回的描述的意义x0dx0aDistinctx0dx0a一旦MYSQL找到了与行相联合匹配的行，就不再搜索了x0dx0aNot existsx0dx0aMYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了x0dx0aRange checked for each Record（index map:#）x0dx0a没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一x0dx0aUsing filesortx0dx0a看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行x0dx0aUsing indexx0dx0a列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候x0dx0aUsing temporaryx0dx0a看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上x0dx0aWhere usedx0dx0a使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）x0dx0aconstx0dx0a表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待x0dx0aeq_refx0dx0a在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用x0dx0arefx0dx0a这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好x0dx0arangex0dx0a这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况x0dx0aindexx0dx0a这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）x0dx0aALLx0dx0a这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免
J. mysql sql优化之 优化GROUP BY 和 DISTINCT
创建表tb_point 表
准备空的tb_box表
函数
编写存储过程，给tb_box表添加100万条数据
修改关联数据
好于
优于
在执行以下语句时会报错：
前面在 https://www.jianshu.com/p/95e50fd017ea 文章中有提到这个问题，是直接修改sql_mode将 ONLY_FULL_GROUP_BY直接干掉。但是在《高性能mysql》中有一段话是这样的：
那么既然指出不要直接修改 sql_mode，那么我们应该如何让冲突的GRUOPBY语句正确执行呢？
文中有提到，可以使用max()和min()函数来实现；但是这种方式使用max和min函数较真的人可能会说这样写的分组查询有问题，确实如此。但是如果更加在乎查询效率，这样做也无可厚非。
如果，实在无法接受使用上面那种方式的话，可以这样使用子查询的方式来进行查询：
书上对于这种方式有描述如下：
这样写更满足关系理论，但是成本有点高，因为子查询需要填充临时表，而子查询中创建的临时表是没有任何索引的。
作者认为这样写对性能有影响。
但是从我测得结果来看，子查询的耗时反而更少。性能反而更佳。这个子查询耗时0.4秒。而使用max方式耗时0.8秒。几乎一倍。我的mysql版本是 5.7.22-log
为了解其中的原因，我们查看它的执行计划：
可见，因为子查询而产生了一层 DERIVED 临时表，但是这个临时表的Extra字段有显示 Using index、key里面显示自建索引。说明用到了索引。这是查询性能可观的一个重要原因吧；
另外我分别使用 SHOW PROFILE命令查看各部分耗时，对比之下。没看到有哪部分耗时差别特别大，使用JOIN、MAX 耗时比上子查询耗时都差不多是1倍
有些时候对一没有建立索引的字段，进行GRUOP BY时。会产生Using filesort 文件内排序。因为GRUOP BY是在排序的基础上进行分组的。
如下面sql：
如果业务上不对排序有要求。那么就可以禁止GRUOP BY的排序：
这样就把Using filesort给干掉了！ 执行时间 1.237
当然，多数情况是多排序有要求的。此时也可以在GRUOP BY后面使用DESC和ASC关键字，使分组的结果集按需要的方向排序。如下：
分组查询的一个变种就是要求mysql对分组结果再进行一次超级聚合。可以使用GROUP BY WITH ROLLUP 来实现这种逻辑，但可能性能不佳。因为通过查询计划分析出它是使用 Using temporary; Using filesort 来实现的。
使用WITH ROLLUP，查询时间2.531秒。不使用0.774 秒。
1、所以，很多时候。我们在应用程序中做超级聚合是最好的！
2、当然也可使用UNION ALL 来实现：
3、还可以通过FROM子句嵌套使用子查询：