Optimizing SQl Queries
Target
1. Reduce IO times
90% of the data consumption in database operations is in IO, so reducing the number of IO is the first consideration.
2. Reduce CPU calculation
order by, group by, distinct, all consume a lot of CPU
Misunderstanding
1. count(1), count(primary_key)比count(*)好
For some scenarios, this may perform worse, and some special optimizations should be made for the count(*) count operation for the database. ? ? ?
Usually I still use count(1) or count(primary_key)
2. count(column) is the same as countd(*)
count(column) is the number of records in the result set whose column fields are not empty
count(*) is how many records there are in the entire result set
3. select a,b from … allows the database to access less data than select a,b,c from …
In fact, the amount of data is the same. Database storage principle
If there is an index, it is different, why is it different? ?
4. order by must require a sorting operation
The index is originally sorted. After adding the index, the sorting operation is generally omitted.
Further reading: Implementation Analysis of MySQL ORDER BY, Basic Implementation Principles of GROUP BY in MySQL and Basic Implementation Principles of MySQL DISTINCT These three articles have more in-depth analysis, especially the first one
The basic principle
1. Use join sparingly
The MySQL optimizer has high efficiency and multi-table join. On the one hand, the optimizer is limited, and on the other hand, MySQL's join is not as good as Oracle's.
2. Minimize sorting
Because sorting takes up a lot of CPU resources, the method of reducing sorting
1. Use index instead of sorting
2. Reduce the number of pieces of data involved in sorting
3. Don't sort the data if you don't need to sort
3. Minimize the use of select *
On the one hand, if order by is used, less data will improve the sorting effect; on the other hand, if the query field happens to be the index field, the speed will be greatly improved
4. Try to use join instead of subqueries
Although the performance of join is not very good, it is still better than subquery
5. Use as little as possible or
MySQL在where 后用or，性能还不如 union all、union，所以建议在必要的时候用 union all 或 union
6. 用 union all 代替 union
因为 union 合并后，会进行唯一性过滤，这涉及到排序，所以会大大占用CPU运算，如果确定数据不会重复或不在乎数据重复的情况下，尽量使用 union all
7. 尽早过滤
在用 join 的时候，可以在 join 子句中做一些简单的过滤，而不用在最后where的时候再以前过滤。
8. 首先优化高并发的SQL，而不是使用频率小的
因为高并发更容易出问题，速度慢一点点都可能压垮系统，而使用频率小的，即使慢一点，系统还是能顶住
9. 统一SQL语句写法
select * from user
SELECT * FROM user
对于我们来说，只是大小写的问题，但对于数据库解析器是要解析两次的，如果统一的话效率会更高。
10. 不要用太复杂的SQL
一般SQL语句不要超过三层嵌套，太多就看不懂，而且数据库解析会更慢，这样维护成本和解析成本都很高。
11. 少用数据库函数
数据库函数有事会根据不同数据库而不同，建议程序做好过使用数据库自带的函数，一是好维护，二是数据库迁移更容易。
12. 可能会导致索引无效的情况，对索引字段进行如下操作
1) like ‘%AA%’
2) 索引字段进行计算操作
3) not，<>，!=
4) is null，is not null
5) 类型转换
6) 索引字段进行函数
13. 从全局出发优化，而不是片面调整
SQL 优化不能是单独针对某一个进行，而应充分考虑系统中所有的 SQL，尤其是在通过调整索引优化 SQL 的执行计划的时候，千万不能顾此失彼，因小失大。
14. 尽可能对每一条运行在数据库中的SQL进行 explain
优化 SQL，需要做到心中有数，知道 SQL 的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后，很明显的问题 SQL 可能已经很少了，大多都需要去发掘，这时候就需要进行大量的 explain 操作收集执行计划，并判断是否需要进行优化。
15. 临时表
参考：http://www.cnblogs.com/ggjucheng/archive/2012/11/11/2765465.html