Oracle SQL 执行计划因 SYS_OP_C2C 内部转换而改变

Question

我想知道为什么这个查询的成本

select * from address a
left join name n on n.adress_id=a.id
where a.street='01';

高于

select * from address a
left join name n on n.adress_id=a.id
where a.street=N'01';

地址表如下所示

ID              NUMBER
STREET          VARCHAR2(255 CHAR)
POSTAL_CODE     VARCHAR2(255 CHAR)

名称表是这样的

ID              NUMBER
ADDRESS_ID      NUMBER
NAME            VARCHAR2(255 CHAR)
SURNAME         VARCHAR2(255 CHAR)

这些是解释计划返回的成本

解释“01”的计划

-----------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                      |  3591 |  1595K|    87   (0)| 00:00:02 |
|   1 |  NESTED LOOPS OUTER          |                      |  3591 |  1595K|    87   (0)| 00:00:02 |
|*  2 |   TABLE ACCESS FULL          | ADDRESS              |     3 |   207 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| NAME                 |  1157 |   436K|    47   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | NAME_HSI             |  1157 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

   2 - filter("A"."STREET"='01')
   4 - access("N"."ADDRESS_ID"(+)="A"."ID")

解释 N'01' 的计划

-----------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                      |   347 |   154K|    50   (0)| 00:00:01 |
|   1 |  NESTED LOOPS OUTER          |                      |   347 |   154K|    50   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL          | ADDRESS              |     1 |    69 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| NAME                 |  1157 |   436K|    47   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | NAME_HSI             |  1157 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

   2 - filter(SYS_OP_C2C("A"."STREET")=U'01')
   4 - access("N"."ADDRESS_ID"(+)="A"."ID")

如您所见，N'01' 查询的成本低于 '01' 的成本。知道为什么吗？ N'01' 需要另外将 varchar 转换为 nvarchar，因此成本应该更高（SYS_OP_C2C()）。另一个问题是为什么N'01'查询处理的行数低于'01'？

[编辑]

• 表 address 有 30 行。
• 表 name 有 19669 行。

Answer 1

SYS_OP_C2C 是一个internal function，它使用TO_NCHAR 函数将varchar2 的implicit conversion 转换为national character set。因此，与使用普通比较的过滤器相比，过滤器完全改变了。

我不确定行数less的原因，但我可以保证它也可能更多。成本估算不会受到影响。

让我们尝试在测试用例中逐步查看。

SQL> CREATE TABLE t AS SELECT 'a'||LEVEL col FROM dual CONNECT BY LEVEL < 1000;

Table created.

SQL>
SQL> EXPLAIN PLAN FOR SELECT * FROM t WHERE col = 'a10';

Explained.

SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     5 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |     5 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

   1 - filter("COL"='a10')

13 rows selected.

SQL>

到目前为止一切顺利。由于只有一行的值为“a10”，因此优化器估计为一行。

我们来看看国家字符集的转换。

SQL> EXPLAIN PLAN FOR SELECT * FROM t WHERE col = N'a10';

Explained.

SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    10 |    50 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |    10 |    50 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

   1 - filter(SYS_OP_C2C("COL")=U'a10')

13 rows selected.

SQL>

这里发生了什么？我们可以看到filter(SYS_OP_C2C("COL")=U'a10')，这意味着应用了一个内部函数，它将varchar2值转换为nvarchar2。过滤器现在找到 10 行。

这也将抑制任何索引的使用，因为现在在列上应用了一个函数。我们可以通过创建function-based index 来调整它以避免full table scan。

SQL> create index nchar_indx on t(to_nchar(col));

Index created.

SQL>
SQL> EXPLAIN PLAN FOR SELECT * FROM t WHERE to_nchar(col) = N'a10';

Explained.

SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 1400144832

--------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |            |    10 |    50 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T          |    10 |    50 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | NCHAR_INDX |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
---------------------------------------------------

   2 - access(SYS_OP_C2C("COL")=U'a10')

14 rows selected.

SQL>

但是，这会使执行计划相似吗？不，我认为使用 两个不同的字符集 ，过滤器将不会被应用。因此，区别就在于此。

我的研究表明，

通常，当数据通过应用程序传入时，会发生这种情况 是nvarchar2类型，但是表列是varchar2。因此，甲骨文 在过滤器操作中应用内部函数。我的建议 是，要很好地了解你的数据，以便你在使用类似的数据类型 设计阶段。

Answer 2

当担心解释计划时，是否有关于表的当前统计信息很重要。如果统计信息不能很好地代表实际数据，那么优化器就会出错并错误地估计基数。

您可以通过查询数据字典来查看多久以前收集的统计信息：

select table_name, last_analyzed
  from user_tables
 where table_name in ('ADDRESS','NAME');

您可以通过调用DBMS_STATS 来收集统计信息以供优化器使用：

begin
   dbms_stats.gather_table_stats(user, 'ADDRESS');
   dbms_stats.gather_table_stats(user, 'NAME');
end;

所以也许在收集统计数据后你会得到不同的解释计划。也许不是。

解释计划的不同主要是因为优化器估计在两种情况下它将在地址表中找到的行数不同。

在第一种情况下，您有一个具有相同数据类型的相等谓词 - 这很好，优化器通常可以合理地估计此类情况下的基数（行数）。

在第二种情况下，将函数应用于列 - 这通常很糟糕（除非您有基于函数的索引）并且会迫使优化器进行疯狂的猜测。在不同版本的 Oracle 中，随着优化器的开发人员试图对其进行改进，这个疯狂的问题会有所不同。在某些版本中，疯狂的猜测只是“我猜是表中行数的 5%”。

在比较不同的数据类型时，最好避免隐式转换，尤其是在这种情况下，隐式转换在 列 上而不是文字上生成函数。如果您的值是数据类型 NVARCHAR2 并且需要在上述谓词中使用它，则最好将值显式转换为列的数据类型。

select * from address a
left join name n on n.adress_id=a.id
where a.street = CAST( N'01' AS VARCHAR2(255));

当然，在这种情况下，使用文字是没有意义的。在这里，您只需使用您的第一个查询。但如果它是一个变量或函数参数，也许你可以用用例来做这样的事情。

Answer 3

我可以看到第一个查询返回 3591 行，第二个查询返回 347 行。所以 Oracle 需要更少的 I/O 操作，这就是成本更低的原因。

不要与

混淆

N'01' 需要另外将 varchar 转换为 nvarchar

Oracle 执行一次硬解析，然后对相同的查询使用软解析。所以你的预言机工作的时间越长，它就会变得越快。