mysql的优化

判断sql是否有问题？

执行sql语句等待响应的快慢可以判断 一般优化至100ms以下(百万级以上数据)

sql语句的表现

　　1）sql语句的冗长

　　2）type为All类型

　　3）Rows超大

　　...可能是存在问题sql

写sql的技巧

　　 1. 合理使用索引，索引少了查询慢；索引多了占用空间大，执行增删改语句的时候需要动态维护索引，影响性能

　　　　1）join字段、distinct、order by 建议索引

　　　　2）文档搜索类型使用全文索引

　　　　3）复合索引要注意从左往右原则

　　2. UNION ALL的执行效率比UNION高，UNION使用时会排重及排序，影响性能

　　3. 减少使用 select * 的情况 sql返回的数据需要什么就拿什么 不要怕麻烦

　　4. 不要使用 where 1=1 的情况，避免 order by rand()

　　5. 建表时使用时间类型 datetime 类型

　　6. 创建索引后要使用对应类型的值 才不会造成隐式转换 导致索引用不上的情况

优化 执行计划 explain / desc

字段	解释
id	每个被独立执行的操作标识，标识对象被操作的顺序，id值越大，先被执行，如果相同，执行顺序从上到下
select_type	查询中每个select 字句的类型
table	被操作的对象名称，通常是表名，但有其他格式
partitions	匹配的分区信息(对于非分区表值为NULL)
type	连接操作的类型
possible_keys	可能用到的索引
key	优化器实际使用的索引(最重要的列) 从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL。当出现ALL时表示当前SQL出现了问题
key_len	被优化器选定的索引键长度，单位是字节
ref	表示本行被操作对象的参照对象，无参照对象为NULL
rows	查询执行所扫描的元组个数（对于innodb，此值为估计值）
filtered	条件表上数据被过滤的元组个数百分比
extra	执行计划的重要补充信息，当此列出现Using filesort , Using temporary 字样时就要小心了，很可能SQL语句需要优化