Mysql慢查询优化

1、打开Mysql的慢查询日志：

方式一：修改my.ini

//定义多少秒的查询算是慢查询，这里定为2秒
long_query_time=2

//5.5及以上版本配置以下
slow-query-log=on
slow_query_log_file="mysql_slow_query.log"

//记录没有使用索引的query
log-query-not-using-indexes

方式二：控制台开启

set global slow_query_lon=ON
set global long_query_time=3600
set global log_querise_not_using_indexes=ON

2、使用EXPLAIN分析sql慢查询语句

上图为使用了索引，下图没有。

type从好到坏依次是：system，const，eq_ref，ref，fulltext，ref_or_null，unique_subquery，index_subquery，range，index_merge，index，ALL

• const：使用惟一索引或者主键，返回记录必定是1行记录的等值where条件时，一般type是const。其余数据库也叫作惟一索引扫描
• eq_ref：出如今要链接过个表的查询计划中，驱动表只返回一行数据，且这行数据是第二个表的主键或者惟一索引，且必须为not null，惟一索引和主键是多列时，只有全部的列都用做比较时才会出现eq_ref
• ref：不像eq_ref那样要求链接顺序，也没有主键和惟一索引的要求，只要使用相等条件检索时就可能出现，常见与辅助索引的等值查找。或者多列主键、惟一索引中，使用第一个列以外的列做为等值查找也会出现，总之，返回数据不惟一的等值查找就可能出现。
• range：索引范围扫描，常见于使用>,<,is null,between ,in ,like等运算符的查询中。
• index，ALL：至关与全表查询

阿里规约要求：至少要达到 range 级别，要求是 ref 级别，若是能够是 consts 最好

3、经常使用慢查询优化

一、索引失效的状况：

• 不在索引列上作任何操做（计算，函数，（自动或者手动）类型装换），会致使索引失效而致使全表扫描；
• 使用不等于(!= 或者<>)的时候，没法使用索引，会致使索引失效
• 使用is not null 或者 is null会致使没法使用索引
• like查询是以%开头，索引会失效变成全表扫描，覆盖索引。
• 若是条件中有or，即便其中有条件带索引也不会使用(这也是为何尽可能少用or的缘由)。要想使用or，又想让索引生效，只能将or条件中的每一个列都加上索引
• 若是mysql使用全表扫描要比使用索引快,则不会使用到索引

二、优化数据库结构

分表分库 

三、优化LIMIT分页

当limit m,n的m过大时，致使每次查询都要先从整个表中找到知足条件 的前M条记录，以后舍弃这M条记录并从第M+1条记录开始再依次找到N条知足条件的记录。若是表很是大，且筛选字段没有合适的索引，且M特别大那么这样的代价是很是高的。

SELECT * FROM pre_forum_post ORDER BY pid ASC LIMIT 7332000,1000

select a.* from pre_forum_post a ,(select tid,position from pre_forum_post ORDER BY pid ASC LIMIT 7332000,1000) b where a.tid=b.tid and a.position=b.position

https://blog.csdn.net/qq_35513598/article/details/79813098

http://www.javashuo.com/article/p-uenudhjc-hk.html