insert
优化若是你在某一时刻有大量的insert
操做,一条一条插入是很是耗时的。insert
语句自己支持一次插入不少条记录,插入记录数上限受sql语句长度限制,通常一次插个几千条是没问题的。在个人 《如何手动实现Try Insert和Insert Or Update》 一文中对于各类状况都有具体的例子,这里就不赘述了。html
explain
语句结果分析SQL自己是一种对机器来讲抽象级别很高的语言,咱们经过SQL告诉DBMS咱们须要什么,而没有告诉它具体要怎么作。DBMS会猜想性地以最优的方法去完成咱们给的任务,可是它每每作得不太好,毕竟不一样业务最优作法各不相同,目前咱们尚未办法让机器彻底理解咱们的业务。因此咱们须要辅助机器,帮助它找到最好的查询逻辑。一般的作法是添加合适的索引,让全部的查询都走索引。在MySQL中,在任何一个select
语句前加上explain
,就能够知道MySQL对这条查询的理解和实际执行逻辑。mysql
下面来分析explain
语句返回的结果。explain
会展现查询涉及到的每张表分析结果,里面有不少参数,咱们通常只须要关注如下几个参数:sql
type优化
type描述表是怎么join
的,按从最好到最坏一共有如下几个值:code
值 | 解释 |
---|---|
system | 表只有一行,是一种特殊的const type |
const | 表里只有一行匹配的记录,join 时能够认为是常量 |
eq_ref | 使用的索引为primary key 或unique not null index |
ref | join 只使用最左前缀匹配原则的普通索引 |
fulltext | 使用全文检索索引 |
ref_or_null | 与ref 差很少,主要是多了NULL值的查询 |
index_merge | 使用了MySQL的索引合并优化 |
unique_subquery | 相似eq_ref ,主要用于包含IN子查询的查询 |
range | 走索引的范围查询 |
index | 索引树被整个扫了,速度比扫表好一点 |
ALL | 整个表被扫,很是糟糕的状况,通常要避免 |
通常作SQL优化,一般出现index
和ALL
都是须要优化的。htm
Extra对象
MySQL查询的附件信息,有时候表明着查询的额外代价,出现 Using filesort
、Using temperary
都表示查询速度不行。blog
Using filesort
表示order by
子句不走索引,使用文件排序,须要对order by
进行优化。Using temperary
表示查询过程当中建立了临时表,一般发生在包含group by
和order by
的查询中。rows和filtered排序
rows
表示MySQL预估的查询须要的行数,filtered
表示根据条件过滤以后的行所占的百分比。值为100表示没有行被过滤掉。因此rows
*filtered
查询须要的总的行数。这个值天然是越小越好。索引
查询优化的策略就是加索引,primary key 和 unique key在根据具体业务定,咱们作优化,通常都是添加普通索引。普通索引分为两种,单个字段的索引和多个字段的联合索引。联合索引的应用场景相对窄一点,若是你要查的数据能够被联合索引所有囊括,直接从索引拿数据,能够考虑使用联合索引。读多写少重复值少散列分布的字段最适合建索引。你能够把你的程序使用到的全部SQL都列出来,一条一条explain
,没有走索引的,就酌情给某个或某几个字段(join
里的字段、where
里的字段都是重点考虑对象)加上索引,直到全部的查询走索引为止。这么作之后,你的查询type正常均可以到达比较好的状况,可是对于包含order by
子句的查询,可能你的Extra信息就不太理想了。Using filesort
和Using temperary
有时候阴魂不散,很难搞。这时候最佳的策略就是变着花样选择排序的字段。好比你的表有一个自增主键,你能够考虑用它做为插入时间来作排序。MySQL自己在这方面的优化很是糟糕,须要耐心地多尝试。