mysql语句优化的几种方法_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.使用检查连接功能查看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、ORDER BY语句优化

这些语句默认都是按照ORDER BY排序的，优化思路都差不多。

1、如果是多表join查询，ORDER BY列应该按照join顺序属于第一个表，如果不在同一个表中，可以考虑冗余列或者合并表。

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比子查询要快，优化器一般能生成更优的执行计划，以余弦的方式加载数据，更高效的处理查询。而子查询生成的临时表同样没有索引，因此效率会低一些。

在目前的实践中，子查询应该尽可能重写为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)

优化思路：

可以从程序业务层入手，先查询id FROM B，然后获取ID的值，逐步与* FROM A拼接起来，转化为* FROM A where ID =?的形式。

优化 UNION

UNION 语句默认会去掉重复记录，需要排序操作，如果结果集很大，成本会很高，建议尽量使用 UNION ALL 语句。对于多分片的 UNION 场景，在数据库分片时就应该确定每个分片中数据的唯一性，不需要使用 UNION 去重。

另外，查询语句之外的WHERE条件并不应用于每个单独的UNION子句，因此在每个UNION子句中添加一个where条件。

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

由于MySQL内存临时表目前还不支持BLOB和TEXT类型，包含这两个类型的查询都需要基于磁盘的临时表，性能会非常低下，所以如无必要，请不要在查询条件中使用这两个类型。

优化思路：

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

2. 如果有很多大字段，可以考虑将它们合并为一个字段。存储一个 200KB 的大字段比存储 20 个 10KB 的字段更高效。

3.考虑使用（）然后存储。