MySQL查询语句很慢？可以试试几种SQL优化
发布时间：2019-12-25 04:07:09 所属栏目：资源 来源：今日头条
导读：连接查询的优化 无论什么 数据库 ，多表连接的查询成本都是比较高的，因此对于高并发应用，应该尽量减少有连接的查询，多表连接的个数不要超过4张表。一般数据量少的时候，连接开小不大，一般不会有性能问题，当数据量变大后，那么性能问题就会比较突出。
 连接查询的优化 无论什么数据库，多表连接的查询成本都是比较高的，因此对于高并发应用，应该尽量减少有连接的查询，多表连接的个数不要超过4张表。一般数据量少的时候，连接开小不大，一般不会有性能问题，当数据量变大后，那么性能问题就会比较突出。所以在数据库初期最好能确定哪个表能成为大表，然后进行反范式设计减少连接的表，例如增加冗余字段等等，或者在业务代码中进行连接计算。 一些经验总结点： 1、ON、USING字句中的列确认有索引，如果连接的顺序为B、A，那么只需在A表的列上创建索引即可，无需在B中建索引，可以减少不必要索引开销。 查询举例： MYSQL会全表扫描B表，对B表的每一行记录去寻找A表记录，所以需用A表COL2列上索引来提高效率。 2、使用EXPLAIN 检查连接，看ROWS列，如果该列值太高，比如几千，上万的，那么就需要考虑是否索引无效后者连接表的顺序不对了。 3、考虑在应用层实现连接查询，例如可以在JAVA中把复杂的查询分解为几个简单查询，得到一个较小的结果集合，处理遍历后，再根据条件获取完整数据，这样做往往更高效，因为把数据分离，更不容易变化，有利于数据库缓存数据。 举例如下： 如果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。 举例如下： 子查询优化 由于子查询可读性比较符合开发人员的思路习惯，所以都习惯编写子查询，但子查询在生产环境中，是最常见的性能瓶颈。 对于数据库来说，大部分情况下，连接比子查询更快，优化器一般可以生成更佳的执行计划，可以余弦装载数据，更高效的处理查询，子查询生成的临时表也没有索引，因此效率会更低。 目前的实践来说，子查询应该尽量改写成JOIN的写法 举个常见的例子 我们可以转化为连接的方式： 优化IN列表 对于IN列表，MySQL会排序里面的值，并使用二分查找方式去定位数据，把IN字句改写成OR形式其实没什么用。IN列表不建议太长，对于高并发业务，建议不超过几十个。优化思路可以转化为多个等于的查询。例如下面的语句，如果ID值很多，其实性能不会太好。 优化思路： 可以从程序业务层出发，先查询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（），再存储。（编辑：瑞安网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |