MySQL中常见的八种SQL错误用法示例(2)-木庄网络博客

外部查询条件不能够下推到复杂的视图或子查询的情况有：

聚合子查询；
含有 LIMIT 的子查询；
UNION 或 UNION ALL 子查询；
输出字段中的子查询；

如下面的语句，从执行计划可以看出其条件作用于聚合子查询之后：

SELECT * 
FROM (SELECT target, 
    Count(*) 
  FROM operation 
  GROUP BY target) t 
WHERE target = 'rm-xxxx'

+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+
| id | select_type | table  | type | possible_keys | key   | key_len | ref | rows | Extra  |
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+
|
1
| PRIMARY  |
 <derived2> 
| ref |
 <auto_key
0
> 
| <auto_key0> |
514
| const |
2
| Using where |
| 2 | DERIVED  | operation | index | idx_4   | idx_4  | 519  | NULL | 20 | Using index |
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+

确定从语义上查询条件可以直接下推后，重写如下：

SELECT target, 
  Count(*) 
FROM operation 
WHERE target = 'rm-xxxx' 
GROUP BY target

执行计划变为：

+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+
| 1 | SIMPLE | operation | ref | idx_4 | idx_4 | 514 | const | 1 | Using where; Using index |
+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+

关于 MySQL 外部条件不能下推的详细解释说明请参考文章：http://mysql.taobao.org/monthly/2016/07/08

7、提前缩小范围

先上初始 SQL 语句：

SELECT * 
FROM  my_order o 
    LEFT JOIN my_userinfo u 
       ON o.uid = u.uid
    LEFT JOIN my_productinfo p 
       ON o.pid = p.pid 
WHERE ( o.display = 0 ) 
    AND ( o.ostaus = 1 ) 
ORDER BY o.selltime DESC 
LIMIT 0, 15

该SQL语句原意是：先做一系列的左连接，然后排序取前15条记录。从执行计划也可以看出，最后一步估算排序记录数为90万，时间消耗为12秒。

+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+
| id | select_type | table | type  | possible_keys | key   | key_len | ref       | rows  | Extra                       |
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+
| 1 | SIMPLE   | o   | ALL  | NULL     | NULL  | NULL  | NULL      | 909119 | Using where; Using temporary; Using filesort    |
| 1 | SIMPLE   | u   | eq_ref | PRIMARY    | PRIMARY | 4    | o.uid |   1 | NULL                        |
| 1 | SIMPLE   | p   | ALL  | PRIMARY    | NULL  | NULL  | NULL      |   6 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+

由于最后 WHERE 条件以及排序均针对最左主表，因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下，执行时间缩小为1毫秒左右。

SELECT * 
FROM (
SELECT * 
FROM  my_order o 
WHERE ( o.display = 0 ) 
    AND ( o.ostaus = 1 ) 
ORDER BY o.selltime DESC 
LIMIT 0, 15
) o 
   LEFT JOIN my_userinfo u 
       ON o.uid = u.uid 
   LEFT JOIN my_productinfo p 
       ON o.pid = p.pid 
ORDER BY o.selltime DESC
limit 0, 15

再检查执行计划：子查询物化后（select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万，但是利用了索引以及 LIMIT 子句后，实际执行时间变得很小。

+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+
| id | select_type | table   | type  | possible_keys | key   | key_len | ref  | rows  | Extra                       |
+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+
| 1 | PRIMARY   | <derived2> | ALL  | NULL     | NULL  | NULL  | NULL |   15 | Using temporary; Using filesort          |
| 1 | PRIMARY   | u     | eq_ref | PRIMARY    | PRIMARY | 4    | o.uid |   1 | NULL                        |
| 1 | PRIMARY   | p     | ALL  | PRIMARY    | NULL  | NULL  | NULL |   6 | Using where; Using join buffer (Block Nested Loop) |
| 2 | DERIVED   | o     | index | NULL     | idx_1  | 5    | NULL | 909112 | Using where                    |
+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+

8、中间结果集下推

再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件)：

SELECT  a.*, 
     c.allocated 
FROM   ( 
       SELECT  resourceid 
       FROM   my_distribute d 
          WHERE  isdelete = 0 
          AND   cusmanagercode = '1234567' 
          ORDER BY salecode limit 20) a 
LEFT JOIN 
     ( 
       SELECT  resourcesid， sum(ifnull(allocation, 0) * 12345) allocated 
       FROM   my_resources 
          GROUP BY resourcesid) c 
ON    a.resourceid = c.resourcesid

那么该语句还存在其它问题吗？不难看出子查询 c 是全表聚合查询，在表数量特别大的情况下会导致整个语句的性能下降。

其实对于子查询 c，左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下，执行时间从原来的2秒下降到2毫秒。

SELECT  a.*, 
     c.allocated 
FROM   ( 
          SELECT  resourceid 
          FROM   my_distribute d 
          WHERE  isdelete = 0 
          AND   cusmanagercode = '1234567' 
          ORDER BY salecode limit 20) a 
LEFT JOIN 
     ( 
          SELECT  resourcesid， sum(ifnull(allocation, 0) * 12345) allocated 
          FROM   my_resources r, 
              ( 
                   SELECT  resourceid 
                   FROM   my_distribute d 
                   WHERE  isdelete = 0 
                   AND   cusmanagercode = '1234567' 
                   ORDER BY salecode limit 20) a 
          WHERE  r.resourcesid = a.resourcesid 
          GROUP BY resourcesid) c 
ON    a.resourceid = c.resourcesid

但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销，还使得整个语句显的繁杂。使用 WITH 语句再次重写：

WITH a AS 
( 
     SELECT  resourceid 
     FROM   my_distribute d 
     WHERE  isdelete = 0 
     AND   cusmanagercode = '1234567' 
     ORDER BY salecode limit 20)
SELECT  a.*, 
     c.allocated 
FROM   a 
LEFT JOIN 
     ( 
          SELECT  resourcesid， sum(ifnull(allocation, 0) * 12345) allocated 
          FROM   my_resources r, 
              a 
          WHERE  r.resourcesid = a.resourcesid 
          GROUP BY resourcesid) c 
ON    a.resourceid = c.resourcesid

总结

数据库编译器产生执行计划，决定着SQL的实际执行方式。但是编译器只是尽力服务，所有数据库的编译器都不是尽善尽美的。

上述提到的多数场景，在其它数据库中也存在性能问题。了解数据库编译器的特性，才能避规其短处，写出高性能的SQL语句。

程序员在设计数据模型以及编写SQL语句时，要把算法的思想或意识带进来。

编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。

更多Mysql内容来自木庄网络博客

标签：Mysql

返回前面的内容