MySQL查询语句很慢如何解决

共计 2066 个字符，预计需要花费 6 分钟才能阅读完成。

今天就跟大家聊聊有关 MySQL 查询语句很慢如何解决，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

连接查询的优化

无论什么数据库，多表连接的查询成本都是比较高的，因此对于高并发应用，应该尽量减少有连接的查询，多表连接的个数不要超过 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 =？的形式。

优化 UNION

UNION 语句默认是去除重复记录，需要用到排序操作，如果结果集很大，成本会很高，建议尽量使用 UNION ALL 语句，对于 UNION 多个分表场景，应尽可能在数据库分表的时候，就确定各个分表数据唯一性，这样就无需使用 UNION 来去重了。

另外查询语句外的 WHERE 条件并不会应用到每个单独的 UNION 子句中，所以每个 UNION 子句都添加 where 条件。

优化 BLOB、TEXT 类型字段的查询

由于 mysql 内存临时表暂不支持 BLOB、TEXT 类型，如果包含他们的查询就要用到基于磁盘的临时表，性能会很低，所以如无必要，查询条件就不要这 2 种类型。

优化思路：

1、如果必须使用，可以考虑拆分表，把 BLOB、TEXT 字段分离到单独的表中。

2、如果有许多大字段，可以考虑合并这些字段到一个字段，存储一个大 200KB 比存储 20 个 10KB 更有效。

3、考虑使用 COMPRESS（），再存储。

看完上述内容，你们对 MySQL 查询语句很慢如何解决有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。