什么是慢查询？

慢查询定义及作用

慢查询日志，顾名思义，就是查询慢的日志，是指mysql记录所有执行超过long_query_time参数设定的时间阈值的SQL语句的日志。该日志能为SQL语句的优化带来很好的帮助。默认情况下，慢查询日志是关闭的，要使用慢查询日志功能，首先要开启慢查询日志功能。

启动慢查询

常用配置

slow_query_log 启动停止技术慢查询日志

slow_query_log_file 指定慢查询日志得存储路径及文件（默认和数据文件放一起）

long_query_time 指定记录慢查询日志SQL执行时间得伐值（单位：秒，默认10秒）

log_queries_not_using_indexes 是否记录未使用索引的SQL

log_output 日志存放的地方【TABLE】【FILE】【FILE,TABLE】

记录符合条件得SQL

查询语句

数据修改语句

已经回滚得SQL    

慢查询日志解析

常用的慢查询日志分析工具（mysqldumpslow）

汇总除查询条件外其他完全相同的SQL，并将分析结果按照参数中所指定的顺序输出。

语法

mysqldumpslow -s r -t 10 slow-mysql.log

 -s order (c,t,l,r,at,al,ar)

         c:总次数

         t:总时间

         l:锁的时间

         r:总数据行

         at,al,ar :t,l,r平均数  【例如：at = 总时间/总次数】

-t  top   指定取前面几天作为结果输出

示例：

mysqldumpslow.pl -s t -t 10 D:\DESKTOP-2EKGEE5-slow.log 

常用的优化方式

服务器硬件

MySql服务器优化

SQL本身优化

反范式设计优化

索引优化

反范式化设计

什么叫反范式化设计?

反范式化是针对范式化而言的

所谓得反范式化就是为了性能和读取效率得考虑而适当得对数据库设计范式得要求进行违反

允许存在少量得冗余，换句话来说反范式化就是使用空间来换取时间

三大范式

数据库设计的第一大范式

数据库表中的所有字段都只具有单一属性

单一属性的列是由基本数据类型所构成的

设计出来的表都是简单的二维表

数据库设计的第二大范式

要求表中只具有一个业务主键，也就是说符合第二范式的表不能存在非主键列只对部分主键的依赖关系

订单编号 和产品ID没有直接关联      

修改后  ——>

数据库设计的第三大范式

指每一个非非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上相处了非主键对主键的传递依赖

客户编号 和订单编号管理 关联

客户姓名 和订单编号管理 关联

客户编号 和 客户姓名 关联

把客户姓名这列删除，只放到客户表中

索引是什么？

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。

可以得到索引的本质：索引是数据结构。

最简单的索引

稍微复杂点的索引

MySql中的索引

上方是数据表，一共有两列七条记录，最左边的是数据记录的物理地址

mysql默认存储引擎innodb只显式支持B-Tree( 从技术上来说是B+Tree)索引 

索引分类

普通索引：即一个索引只包含单个列，一个表可以有多个单列索引

唯一索引：索引列的值必须唯一，但允许有空值

复合索引：即一个索引包含多个列

创建索引 

 CREATE  [UNIQUE ] INDEX indexName ON mytable(columnname(length)); 

 ALTER TABLE 表名 ADD  [UNIQUE ]  INDEX [indexName] ON (columnname(length)) 

查看索引

 SHOW INDEX FROM table_name

删除索引

DROP INDEX [indexName] ON mytable

执行计划

执行计划是什么？

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈

语法

Explain + SQL语句

执行计划的作用

表的读取顺序

数据读取操作的操作类型

哪些索引可以使用

哪些索引被实际使用

表之间的引用

每张表有多少行被优化器查询

执行计划包含的信息

执行计划-ID

执行计划-select_type

执行计划-table

显示这一行的数据是关于哪张表的

执行计划-type

type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：

system> const > eq_ref > ref > fulltext > ref_or_null > index_merge> unique_subquery > index_subquery > range > index > ALL

需要记忆的

system>const>eq_ref>ref>range>index>ALL

执行计划-key_len

key_len表示索引使用的字节数

根据这个值，就可以判断索引使用情况，特别是在组合索引的时候，判断所有的索引字段是否都被查询用到。

char和varchar跟字符编码也有密切的联系,

latin1占用1个字节，gbk占用2个字节，utf8占用3个字节。（不同字符编码占用的存储空间不同）

索引优化策略

策略1.尽量全值匹配

EXPLAIN

SELECT * FROM staffs WHERE NAME = 'July';

EXPLAIN

SELECT * FROM staffs WHERE NAME = 'July' AND age = 25;

EXPLAIN

SELECT * FROM staffs WHERE NAME = 'July' AND age = 25 AND pos = 'dev';

策略2.最佳左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

策略3.不在索引列上做任何操作

不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

EXPLAIN SELECT * FROM staffs WHEREleft(NAME,4) = 'July';

策略4.范围条件放最后

存储引擎不能使用索引中范围条件右边的列

策略5.覆盖索引尽量用

尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select*

策略6.不等于要甚用

mysql在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描

策略7.Null/Not有影响

注意null/notnull对索引的可能影响

策略8.Like查询要当心

like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作

策略9.字符类型加引号

字符串不加单引号索引失效

策略10.OR改UNION效率高

全值匹配我最爱，最左前缀要遵守；

带头大哥不能死，中间兄弟不能断；

索引列上少计算，范围之后全失效；

LIKE百分写最右，覆盖索引不写*；

不等空值还有OR，索引影响要注意；

VARCHAR引号不可丢，SQL优化有诀窍。