sql语句时间花在哪了？
1 等待时间 2 执行时间
这两个时间并非孤立的，单条语句执行的快 其他语句等待的时间就少
执行时间花在哪了？
1 查找 沿着索引查找 慢者可能全表扫描
2 取出 查到行后，把数据取出来（sending data）
如何查询快？
1 查询快 联合索引的顺序 区分度 长度
2 取的快 索引覆盖（不回行）
3 传输的少 ，更少的行和列
切分查询：按数据拆分多次
插入1w行数据，每1000条为单位插入
分解查询：按逻辑把多表连接查询分成多个简单的sql
sql语句优化思路
不查 通过业务逻辑来计算
少查 尽量精准数据，少取行
高效的查 走索引查
explain分析：
explain select user_id,name from sys_user
id 查询序号 有几个id就是查询了几次
select_type 简单查询
table 查询表
type 索引扫描多少
possible_keys 系统估计可能用到的键 只能用1个
key 真正用到的键
key_len 用到的键长度
ref 联查引用关系
rows 估计本次查多少行
extra 额外信息
select_type 类型：
simple (不含子查询)
primary( 含子查询或派生查询 )
--> subquery ( 非from子查询)
--> derived (from型子查询)
--> union
--> union result (往往和union同时出现）
table ：
可能是 ：
1 实际表名 select * from t1
2 表的别名 select * from t2 as a
3 derived from 子查询时
4 null 没有from
possible_keys：
可能用到的索引，但最终，只能用到1个
key：
最终使用到的索引
key_len
使用索引的最大长度
表达式用不上索引!
如select * from goods where goods_id +1 > 31
type类型:
1 all 扫描所以的数据，意味着从表的第一行往后全表扫描 运气不好扫描到最后一行 最慢
select * from email where uname = 'lisi'
2 index 扫描所有的索引节点 比all快点
select email from email where ...
3 range 查询时，能根据索引做范围的扫描
select * from goods where good_id > 25
4 ref 通过索引列，可以直接引用到某些数据行
select good_id from goods where cat_id = 25
5 eq_ref 通过索引列，可以直接引用到某1行数据 常见连接查询中
6 const system null 这3个分别值查询优化到常量级别，甚至不需要查找时间
一般按主键查询时 易出现const system
直接查询某个表达式 不经过表时 出现null
ref 类型：
连接查询时，表之间的字段引用关系（2个表关联的那个字段）
rows:
估计要扫描多少行
extra：
1 using index 索引覆盖 效率非常高 不需要回行
2 using where 光靠索引定位不了 还得配合where判断一下
3 using temporary 指用上了临时表
4 using filesort 文件排序（可能在内存或磁盘） 比较长的列如text列 就要在磁盘上排序了
in 型子查询引出的陷阱
题：在商城表中 查询6号栏目的商品，6号是一个大栏目里面有78911小栏目
select * from goods where cat_id in (select cat_id from category where parent_id = 6)
误区：给我们的感觉是先查到内存的6号栏目的子栏目 然后外层cat_id in (7,8,9,11)
事实，goods表全盘扫描并逐行与category 表对照看parent_id = 6 是否成立
原因：mysql查询优化器，针对in型做优化，被改成了exists子查询的执行结果 当goods表越大时，查询速度越慢
改进： 用连接查询来代替子查询
select * from goods inner join (select cat_id from category where parent_id = 6) as tmp
on goods .cat_id = tmp.cat_id
exists 子查询也会有这种问题
from型子查询
内层from语句查到的临时表，是没有索引的 所以from的返回内容要尽量少 需要排序 在内层先排好序
count和union
1 count优化：
误区：
1 myisam的count（）非常快
仅限于所有行比较快，因为myisam对行数进行了存储，一旦有条件的查询，速度就不再快了 尤其是where条件的列上没有索引
2 想查id>= 100的列 很慢
小技巧：查id<100 在用总数减
select count(*) from com 快
select count(*) from com where id<100 快
select count(*) from com - select count(*) from com where id<100 快
3 group by
注意：
1 分组用于统计，不用于筛选重复数据
用 group by 去重效率低
group by 列要有索引 可以避免临时表和文件排序
2 以ab表连接为例 主要查询a表的列
那么group by，order by 的列尽量相同，而且列应该显示声明为a的列
select * from a inner join b group by a.cat_id order a.cat_id
4 union 优化
union一定要用到临时表
注意： 1 union 的字句条件要尽量具体 即 查询更少的行
2 字句的结果在内存里并成结果集 需要去重复 去重复就得先排序 而加all之后，不需要去重
所以union尽量加all
limit 及 翻页优化
select * from table limit m,n
select * from table limit 100,3
指从第100条开始 往后取3条，不过实际上不是直接数到100取的 而且取103条再把前100条扔了
所以 offset 越大 效率越低 （m）
优化方法：
1 从业务上去解决 办法： 不允许翻到100页 以百度为例 一般翻页只能到70多页(推荐）
2 不用offset 用条件查询
改成 where id > 100 limt 3;(要求 id 不能缺 缺了就不等效了）
好处： 可以用索引
问题：如果id缺了 2次结果不一致
原因： 数据被物理删除过，有空洞
解决：数据不进行物理删除（可以逻辑删除） 最终在页面上显示数据时，逻辑删除的条目不显示即可
（一般来说大网站的数据都是不物理删除的，只做逻辑删除，如is_delete=1）
3 非要物理删除，还要用offset精确查询，还不限制用户分页怎么办
select * from lx_com
inner join
(select id from lx_com limit 100000,3)as tmp
on lx_com.id = tmp.id
分析： 优化思路是 不查 少查 查索引 少取列
我们现在必须要查，则只查索引 不查数据 得到id 再用id去查具体条目，这种技巧就是延迟关联