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