mysql查询语句很慢?可以试试几种SQL优化


mysql查询语句很慢?可以试试几种SQL优化

文章插图
 
连接查询的优化无论什么数据库 , 多表连接的查询成本都是比较高的 , 因此对于高并发应用 , 应该尽量减少有连接的查询 , 多表连接的个数不要超过4张表 。一般数据量少的时候 , 连接开小不大 , 一般不会有性能问题 , 当数据量变大后 , 那么性能问题就会比较突出 。所以在数据库初期最好能确定哪个表能成为大表 , 然后进行反范式设计减少连接的表 , 例如增加冗余字段等等 , 或者在业务代码中进行连接计算 。
一些经验总结点:
1、ON、USING字句中的列确认有索引 , 如果连接的顺序为B、A , 那么只需在A表的列上创建索引即可 , 无需在B中建索引 , 可以减少不必要索引开销 。
查询举例:
SELECT B.*,A.* FROM B JOIN A ON B.col1 = A.col2 
MySQL会全表扫描B表 , 对B表的每一行记录去寻找A表记录 , 所以需用A表COL2列上索引来提高效率 。
 
2、使用EXPLAIN 检查连接 , 看ROWS列 , 如果该列值太高 , 比如几千 , 上万的 , 那么就需要考虑是否索引无效后者连接表的顺序不对了 。
 
3、考虑在应用层实现连接查询 , 例如可以在JAVA中把复杂的查询分解为几个简单查询 , 得到一个较小的结果集合 , 处理遍历后 , 再根据条件获取完整数据 , 这样做往往更高效 , 因为把数据分离 , 更不容易变化 , 有利于数据库缓存数据 。
举例如下:
SELECT a.* FROM A WHERE a.id IN(1,2,3,4,5,6,7,8,9,10);如果id=1~8的记录已经被存储在缓存redis中了 , 那么我们只需要查询id=9和10的数据 , 这样减少了很多数据库连接交互 , 可以提高性能 。
GROUP BY、DISTINCT、ORDER BY 语句优化这些语句默认都要进行ORDER BY排序 , 优化的思路比较类似 。
1、如果多张表进行连接查询 , ORDER BY 的列应属于连接顺序的第一张表 。如果不在同一个表中 , 那么可以考虑冗余一些列 , 或者合并表 。
2、需要保证索引列和ORDER BY的列相同 , 且各列按照相同的方向进行排序 。
3、指定ORDER BY NULL , 默认情况下 , MYSQL将排序所有GROUP BY的查询 , 如果想要避免排序结果所产生的消耗 , 可以指定ORDER BY NULL 。
举例如下:
select count(1) from sys_dept group by dept_id order by null limit 3子查询优化由于子查询可读性比较符合开发人员的思路习惯 , 所以都习惯编写子查询 , 但子查询在生产环境中 , 是最常见的性能瓶颈 。
对于数据库来说 , 大部分情况下 , 连接比子查询更快 , 优化器一般可以生成更佳的执行计划 , 可以余弦装载数据 , 更高效的处理查询 , 子查询生成的临时表也没有索引 , 因此效率会更低 。
目前的实践来说 , 子查询应该尽量改写成JOIN的写法
举个常见的例子
SELECT c1 FROM t1 where t1.c1 IN (SELECT c1 FROM t2);我们可以转化为连接的方式:
SELECT c1 FROM t1.c1 FROM t1,t2 WHERE t1.c1=t2.c2优化IN列表对于IN列表 , MySQL会排序里面的值 , 并使用二分查找方式去定位数据 , 把IN字句改写成OR形式其实没什么用 。IN列表不建议太长 , 对于高并发业务 , 建议不超过几十个 。优化思路可以转化为多个等于的查询 。例如下面的语句 , 如果ID值很多 , 其实性能不会太好 。
SELECT * FROM A where A.ID IN(SELECT id FROM B)优化思路:
可以从程序业务层出发 , 先查询SELECT id FROM B , 然后获取到ID的值 , 逐步和 SELECT * FROM A进行拼接 , 转化为 SELECT * FROM A where ID =?的形式 。
优化UNIONUNION语句默认是去除重复记录 , 需要用到排序操作 , 如果结果集很大 , 成本会很高 , 建议尽量使用UNION ALL 语句 , 对于UNION多个分表场景 , 应尽可能在数据库分表的时候 , 就确定各个分表数据唯一性 , 这样就无需使用UNION来去重了 。
另外查询语句外的WHERE条件并不会应用到每个单独的UNION子句中 , 所以每个UNION子句都添加where条件 。


推荐阅读