首页 / MYSQL / 统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟

统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10049字，纯文字阅读大概需要15分钟。

内容图文

一天查看数据库长会话，发现1个sql跑得很慢，1个多小时不出结果，花了点时间把它给优化了。优化前： SELECT 20131023, A2.ORG_ID, COUNT(DISTINCT NLSSORT(CASE A2.RES_TYPE WHEN DP THEN A2.RES_CODE END, nls_sort=BINARY)), COUNT(DISTINCT NLSSORT(CASE

一天查看数据库长会话，发现1个sql跑得很慢，1个多小时不出结果，花了点时间把它给优化了。

优化前：

SELECT 20131023,
       "A2"."ORG_ID",
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'DP' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'BOX' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'ONU' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'OBD' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '001' AND "A2"."RES_TYPE" = 'DP') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '002' AND "A2"."RES_TYPE" = 'BOX') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0011' AND "A2"."RES_TYPE" = 'ONU') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0022' AND "A2"."RES_TYPE" = 'OBD') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY'''))
  FROM "CRM_SZ"."AAA" "A2",
       "CRM_SZ"."BBB" "A1"
 WHERE "A1"."RES_ID"(+) = "A2"."RES_CODE"
 GROUP BY "A2"."ORG_ID"

执行计划：
Plan hash value: 2627707252
 
---------------------------------------------------------------------------------------
| Id  | Operation           | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                 |     1 |  1065 |     3  (34)| 00:00:01 |
|   1 |  SORT GROUP BY      |                 |     1 |  1065 |     3  (34)| 00:00:01 |
|   2 |   NESTED LOOPS OUTER|                 |     1 |  1065 |     2   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| AAA             |     1 |   539 |     2   (0)| 00:00:01 |
|*  4 |    INDEX FULL SCAN  | IX_MO_CON_VALUE |     1 |   526 |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access("A1"."RES_ID"(+)="A2"."RES_CODE")
       filter("A1"."RES_ID"(+)="A2"."RES_CODE")

cbo估算错了，rows全是1，导致走nl
手工count了一把：
select count(*) from "CRM_SZ"."AAA" ;--1365564
select count(*) from "CRM_SZ"."BBB";--119949
走nl那岂不是sb啦。

第一次优化后：

SELECT/*+use_hash(A1,A2) swap_join_inputs(A1)*/20131023,
       "A2"."ORG_ID",
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'DP' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'BOX' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'ONU' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'OBD' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '001' AND "A2"."RES_TYPE" = 'DP') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '002' AND "A2"."RES_TYPE" = 'BOX') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0011' AND "A2"."RES_TYPE" = 'ONU') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0022' AND "A2"."RES_TYPE" = 'OBD') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY'''))
  FROM "CRM_SZ"."AAA"        "A2",
       "CRM_SZ"."BBB" "A1"
 WHERE "A1"."RES_ID"(+) = "A2"."RES_CODE"
 GROUP BY "A2"."ORG_ID"

63 rows selected.

Elapsed: 00:00:47.64

Execution Plan
----------------------------------------------------------
Plan hash value: 3074972763

------------------------------------------------------------------------------------------
| Id  | Operation              | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                 |     1 |  1065 |     4  (50)| 00:00:01 |
|   1 |  SORT GROUP BY         |                 |     1 |  1065 |     4  (50)| 00:00:01 |
|*  2 |   HASH JOIN RIGHT OUTER|                 |     1 |  1065 |     3  (34)| 00:00:01 |
|   3 |    INDEX FULL SCAN     | IX_MO_CON_VALUE |     1 |   526 |     0   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL   | AAA             |     1 |   539 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("A1"."RES_ID"(+)="A2"."RES_CODE")

Statistics
----------------------------------------------------------
       1065  recursive calls
          3  db block gets
      13375  consistent gets
      16369  physical reads
          0  redo size
       4862  bytes sent via SQL*Net to client
        791  bytes received via SQL*Net from client
          6  SQL*Net roundtrips to/from client
         12  sorts (memory)
          1  sorts (disk)
         63  rows processed

第二次优化后：

SELECT/*+use_hash(A1,A2) full(A1) full(A2) parallel(A1,5) parallel(A2,5) swap_join_inputs(A1)*/20131023,
       "A2"."ORG_ID",
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'DP' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'BOX' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'ONU' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE"
                       WHEN 'OBD' THEN
                        "A2"."RES_CODE"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '001' AND "A2"."RES_TYPE" = 'DP') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '002' AND "A2"."RES_TYPE" = 'BOX') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0011' AND "A2"."RES_TYPE" = 'ONU') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY''')),
       COUNT(DISTINCT NLSSORT(CASE
                       WHEN ("A1"."CON_TYPE" = '0022' AND "A2"."RES_TYPE" = 'OBD') THEN
                        "A1"."RES_ID"
                     END,
                     'nls_sort=''BINARY'''))
  FROM "CRM_SZ"."AAA"        "A2",
       "CRM_SZ"."BBB" "A1"
 WHERE "A1"."RES_ID"(+) = "A2"."RES_CODE"
 GROUP BY "A2"."ORG_ID";

63 rows selected.

Elapsed: 00:00:10.21

Execution Plan
----------------------------------------------------------
Plan hash value: 4044842257

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                       |     1 |  1065 |     6  (34)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                |                       |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)          | :TQ10004              |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,04 | P->S | QC (RAND)  |
|   3 |    SORT GROUP BY               |                       |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,04 | PCWP |            |
|   4 |     PX RECEIVE                 |                       |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,04 | PCWP |            |
|   5 |      PX SEND HASH              | :TQ10003              |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,03 | P->P | HASH       |
|   6 |       SORT GROUP BY            |                       |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,03 | PCWP |            |
|   7 |        PX RECEIVE              |                       |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,03 | PCWP |            |
|   8 |         PX SEND HASH           | :TQ10002              |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,02 | P->P | HASH       |
|   9 |          SORT GROUP BY         |                       |     1 |  1065 |     6  (34)| 00:00:01 |  Q1,02 | PCWP |            |
|* 10 |           HASH JOIN RIGHT OUTER|                       |     1 |  1065 |     5  (20)| 00:00:01 |  Q1,02 | PCWP |            |
|  11 |            PX RECEIVE          |                       |     1 |   526 |     2   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  12 |             PX SEND HASH       | :TQ10000              |     1 |   526 |     2   (0)| 00:00:01 |  Q1,00 | P->P | HASH       |
|  13 |              PX BLOCK ITERATOR |                       |     1 |   526 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|  14 |               TABLE ACCESS FULL| BBB                   |     1 |   526 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
|  15 |            PX RECEIVE          |                       |     1 |   539 |     2   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  16 |             PX SEND HASH       | :TQ10001              |     1 |   539 |     2   (0)| 00:00:01 |  Q1,01 | P->P | HASH       |
|  17 |              PX BLOCK ITERATOR |                       |     1 |   539 |     2   (0)| 00:00:01 |  Q1,01 | PCWC |            |
|  18 |               TABLE ACCESS FULL| AAA                   |     1 |   539 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  10 - access("A1"."RES_ID"(+)="A2"."RES_CODE")


Statistics
----------------------------------------------------------
        585  recursive calls
          4  db block gets
      14267  consistent gets
      13126  physical reads
        808  redo size
       4888  bytes sent via SQL*Net to client
        840  bytes received via SQL*Net from client
          6  SQL*Net roundtrips to/from client
         23  sorts (memory)
          0  sorts (disk)
         63  rows processed

优化前，执行计划走了nl，1个多小时查不出结果
第一次优化后，首次00:00:47.64可以出结果
第二次优化后，首次00:00:10.21出结果，重复执行（有缓存）的情况下3s出结果。

内容总结

以上是互联网集市为您收集整理的统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟全部内容，希望文章能够帮你解决统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/562187.html

来源：【匿名】

【上一篇】【翻译自mos文章】使用aum（AutomaticUndoManagement）时遇到ORA 【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟】教程文章相关的互联网学习教程文章

在MySQL中使用explain查询SQL的执行计划【代码】

1、什么是MySQL执行计划要对执行计划有个比较好的理解，需要先对MySQL的基础结构及查询基本原理有简单的了解。 MySQL本身的功能架构分为三个部分，分别是应用层、逻辑层、物理层，不只是MySQL ，其他大多数数据库产品都是按这种架构来进行划分的。应用层，主要负责与客户端进行交互，建立链接，记住链接状态，返回数据，响应请求，这一层是和客户端打交道的。逻辑层，主要负责查询处理、事务管理等其他数据库功能处...

MySQL EXPLAIN 命令: 查看查询执行计划【代码】

MySQL 的 EXPLAIN 命令可以查看SELECT语句的执行的计划，是 MySQL 查询优化的必备工具。通过执行计划可以了解查询方式、索引使用情况、需要扫描的数据量以及是否需要临时表或排序操作等信息。我们需要分析执行计划对查询进行有的放矢的优化。需要注意:EXPLAIN不考虑触发器、存储过程或用户自定义函数对查询的影响EXPLAIN不考虑缓存EXPLAIN只能分析执行计划，不能显示存储引擎在执行查询过程中进行的操作部分统计信息是估算的，并非...

MySQL执行计划explain的key_len解析

作者：沃趣科技高级数据库专家邱文辉前言当用Explain查看SQL的执行计划时，里面有列显示了 key_len 的值，根据这个值可以判断索引的长度，在组合索引里面可以更清楚的了解到了哪部分字段使用到了索引。下面演示中，表结构的合理性这边暂且不说，只是证明一下索引长度的计算方法。目前大部分博文是字符类型的索引长度计算方法，下面列举几个类型的索引长度计算方法：1、整数类型(dg1)root@127.0.0.1 [mytest]> desc table_key;+-...

( 转 ) MySQL高级之 explain执行计划详解【图】

使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。explain执行计划包含的信息其中最重要的字段为：id、type、key、rows、Extra各字段详解idselect查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序三种情况： 1、id相同：执行顺序由上至下 2、id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行 3、id相同...

[MySQL] explain执行计划解读【代码】【图】

Explain语法EXPLAIN SELECT …… 变体： 1. EXPLAIN EXTENDED SELECT …… 将执行计划“反编译”成SELECT语句，运行SHOW WARNINGS 可得到被MySQL优化器优化后的查询语句 2. EXPLAIN PARTITIONS SELECT …… 用于分区表的EXPLAIN执行计划包含的信息 id包含一组数字，表示查询中执行select子句或操作表的顺序 id相同，执行顺序由上至下如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行 id如果相同，可以认为是一组，...

mysql 执行计划的理解

1、执行计划就是在sql语句之前加上explain，使用desc 也可以。2、desc有两个选项extended和partitions，desc extended 将原sql语句进行优化，通过show warnings 可以看到优化后的sql语句。 desc partitions 可以查看使用分区表的信息。3、比如：mysql> desc select * from student;+----+-------------+---------+------+---------------+------+---------+------+------+-------+| id | select_type | table | type | possibl...

MySQL——通过EXPLAIN分析SQL的执行计划

在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。下面分别对EXPLAIN命令结果的每一列进行说明：select_type:表示SELECT的类型，常见的取值有：类型说明SIMPLE简单表，不使用表连接或子查询PRIMARY主查询，即外层的查询UNIONUNION中的第二个或者后面的查询语句SUBQUERY子查询中的第一个table:输出结果集的表（表别名）type:表示MySQL在表中找到所需行的方...

mysql执行计划初步解读2【代码】

继续上次没有写完的执行计划部分6.possible_keys可能使用到的索引，这个的理解呢，表示查询时可能使用的索引。只是可能用到，但是并不一定用到。如果是空的，表明肯定是没有相关的索引。但是如果有值，也不一定能够用到。7.key实际使用的索引。6，7的话一起来看下面的例子： mysql> explain select * from `order` where seller_id = 19; +----+-------------+-------+------------+------+------------------+------+---------+...

MySQL执行计划【代码】【图】

MySQL 使用 explain + sql 语句查看执行计划，该执行计划不一定完全正确但是可以参考。EXPLAINSELECT * FROMuserWHERE nid = 3;select_type说明SIMPLE简单查询PRIMARY最外层查询SUBQUERY映射为子查询DERIVED子查询UNION联合UNION RESULT使用联合的结果table : 正在访问的表名type说明ALL全数据表扫描index全索引表扫描RANGE对索引列进行范围查找INDEX_MERGE合并索引，使用多个单列索引搜索REF根据索引查找一个或多个值EQ_REF搜索时...

Oracle从缓存里面查找真实的执行计划【图】

有关Oracle 的执行计划说明，参考：Oracle Explain Plan 有关Oracle 的执行计划说明，参考：Oracle Explain Plan 见一. 查看当前session 的SIDSYS@anqing1(rac1)> SELECT USERENV(SID) FROM DUAL;USERENV(SID)--------------137SYS@anqing1(rac1)> SELECT SID FROM V$MYSTAT WHERE ROWNUM =1;SID----------137 二. 查看缓存中的Explain Plan1）根据SID，从v$sql中找到相应SQL的HASH_VALUE和ADDRESS/* Formatted on 2011/6/20 1...

MySQL执行计划extra中的using index 和 using where using index 的区别【代码】【图】

MySQL执行计划中的extra列中表明了执行计划的每一步中的实现细节，其中包含了与索引相关的一些细节信息其中跟索引有关的using index 在不同的情况下会出现Using index， Using where Using index ，Using index condition等那么Using index 和 Using where;Using index 有什么区别？网上搜了一大把文章，说实在话也没怎么弄懂，于是就自己动手试试。本文仅从最简单的单表去测试using index 和 using where using index以及简单测试...

MySQL执行计划分析工具EXPLAIN用法详解_PHP教程【图】

MySQL执行计划分析工具EXPLAIN用法详解对于DBA来讲熟悉SQL的执行计划分析技巧对于快速定位数据库性能问题至关重要，下面简单介绍一下如何分析MySQL的执行计划。一、EXPLAIN用法详解：EXPLAIN SELECT …… 变体： 1. EXPLAIN EXTENDED SELECT ……将执行计划“反编译”成SELECT语句，运行SHOW WARNINGS 可得到被MySQL优化器优化后的查询语句 2. EXPLAIN PARTITIONS SELECT ……用于分区表的EXPLAIN示例如下所示：具体解释如下1.执行...

MySQL执行计划explain的key_len解析

.0.1 [mytest]> desc table_key; +---------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+---------+-------+ | id | int(11) | NO | | NULL | | | sid | bigint(20) | NO | | 0 | | | name | char(10) | YES | | NULL | | | age | tinyint(4) | Y...

mysql 执行计划的理解

网站优化—mysql explain执行计划【图】

：通过上面的步骤就可以对MySQL进行调优，只要将上面的步骤重复不断执行，可以使用MySQL在最优的情况下工作。?profile定义：MySQL提供的一个可以分析SQL语句执行过程的工具，通过它大致可以了解到MySQL将如何执行用户传递过来的sql语句。用法使用的时候只要在对应的sql语句前面，加上关键字explain 或者同义词 desc # desc select * from tableName where id = 1000000; # explain select * from tableName where id = 1000000; ...

首页 / MYSQL / 统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟

统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟

内容导读

内容图文

内容总结

内容备注

内容手机端

【统计信息不准导致执行计划出错跑不出结果，优化后只要1分钟】教程文章相关的互联网学习教程文章

统计 - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程