#头条创作挑战赛#

慢sql分析

查询生成慢sql的位置，通过命令复制到docker容器外

docker cp centos7_mysql57:/var/lib/mysql/e2d0077fb342-slow.log $PWD

打开文件，复制sql到Navicat执行

查询耗时20s

使用 explain 分析sql执行过程

表的读取顺序数据读取操作的操作类型哪些索引可以使用哪些索引被实际使用表之间的引用每张表有多少行被优化器查询

rows表示扫描的行数

explain表字段的含义：

id: 编号 select_type: 查询类型 table: 表 type: 类型 possible_keys: 预测用到的索引 key: 实际用到的索引 key_len: 使用的索引长度 ref: 表之间的匹配条件 rows：查找到记录所扫描的行数 extra： 额外的 在这个里面会告诉你，我们脚本是否有使用条件

EXPLAIN SELECT EXPLAIN SELECTca.id,ca.username,ca.gqidFROMcb_account caWHERE idIN(SELECT DISTINCT(user_id) from cb_order co);

在id相同时，sql执行的执行过程：从上往下执行，子查询先执行

select_type: 查询类型 - 枚举含义PRIMARY：查询中包含复杂的子查询，最外层的select被标记为PRIMARYSUBQUERY：子查询的第一个selectSIMPLE：简单的SELECT，不使用union或子查询UNION：union中第二个或后面的select语句DEPENDENT UNION： union中的第二个或后面的select语句，取决于外面的查询UNION RESULT: union的结果DEPENDENT SUBQUERY：子查询中的第一个select，取决于外面的查询DERIVED：衍生查询，使用了临时表(select、from子句的子查询)UNCACHEABLE SUBQUERY： 一个子查询的结果不能被缓存，必须重新评估外链接的第一行type: 类型 - 枚举含义

system ，const：MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访 问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量,system是const类型的特例，当查询的表只有一行的情况下，使用system

eq_ref：类似ref，只是使用的索引为唯一索引

ref：使用了索引列上值进行查询

range：使用一个索引来检索给定范围的行

index：索引 遍历索引数据Full index scan

ALL : 全表扫描，你要找数据，要全表查找 影响性能

NULL: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引

性能效率排行 system > const > eq_ref > ref > range > index > all

extra 类型 - 枚举含义 using where：显示的字段，不在索引 Using index： 使用了索引，不 用回表查询，能够起到性能提升 Using temporary： 使用了临时表，消耗比较大，常见于group by语句 Using filesort：使用文件排序，无法利用索引完成排序操作，性能消耗非常大 Using join buffer：mysql引擎使用了连接缓存 Impossible where: where 子句永远为false Select tables optimized away：仅通过使用索引，优化器可能仅从聚合函数结果中返回一行优化慢 sql

type：ALL 表示为全表扫描

rows：查找了14w的数据

key 为空说明没有使用索引

优化点：建立mobile的索引

建立索引

使用索引后,查询时间由20s优化到0.3s

SQL优化方法写on语句时，将数据量小的表放左边，小表写左边，大表写右边where后面的条件尽可能用索引字段，复合索引时，最好按复合索引顺序写where条件where后面有in语句，in字段的索引，最好放复合索引的后面，因为in的字段索引可能会失效模糊查询时，尽量用常量开头，不要用%开头，用%开头查询索引将失效

减少不要使用or，否则索引失效减少使用类型转换(显式、隐式),因其会导致索引失效如果主查询数据量大，则使用in，如果子查询数据量大，则使用exists查询哪些列查询那些列，就根据哪些列group by，不然会产生一个临时表