判断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语句需要优化 |