1

我正在使用 Oracle 11gR2 和 Hibernate 4.2.1。我的应用程序是一个搜索应用程序。

只有 SELECT 操作，它们都是本机查询。

Oracle 默认使用区分大小写的排序。我想将其覆盖为不区分大小写。

我在这里看到了几个选项http://docs.oracle.com/cd/A81042_01/DOC/server.816/a76966/ch2.htm#91066

现在我在执行任何搜索之前使用此查询。

ALTER SESSION SET NLS_SORT='BINARY_CI'

如果我在执行搜索查询之前执行上述 sql，则休眠大约需要 15 分钟才能从搜索查询返回。如果我在 Sql Developer 中执行此操作，它会在几秒钟内返回。

为什么会出现这种两种不同的行为，我该怎么做才能摆脱这种缓慢？

注意：我总是为每次搜索打开一个新的 Hibernate 会话。

这是我的sql：

SELECT *
FROM (SELECT
        row_.*,
        rownum rownum_
      FROM (SELECT
               a, b, c, d, e,
               RTRIM(XMLAGG(XMLELEMENT("x", f || ', ') ORDER BY f ASC)
                     .extract('//text()').getClobVal(), ', ') AS f,
               RTRIM(
                  XMLAGG(XMLELEMENT("x", g || ', ') ORDER BY g ASC)
                  .extract('//text()').getClobVal(), ', ')    AS g
             FROM ( SELECT src.a, src.b, src.c, src.d, src.e, src.f, src.g
                      FROM src src
                     WHERE upper(pp) = 'PP'
                       AND upper(qq) = 'QQ'
                       AND upper(rr) = 'RR'
                       AND upper(ss) = 'SS'
                       AND upper(tt) = 'TT')
             GROUP BY a, b, c, d, e
             ORDER BY b ASC) row_
      WHERE rownum <= 400
) WHERE rownum_ > 0;

LIKE操作自带so may fields，是动态sql查询。如果我使用order by upper(B) ascSql Developer 也需要同样的时间。但按上层结果排序与 相同NLS_SORT=BINARY_CI。我使用过UPPER('B')索引，但没有什么对我有用。

A 的长度 = 10-15 个字符

B 的长度 = 34-50 个字符

C 的长度 = 5-10 个字符

A、B 和 C 是可通过应用程序排序的字段。这个 SRC 表有 300 万多条记录。我们最终得到了一个 SRC 表，它是一个物化视图。

SQL的业务逻辑完全没问题。所有的排序表字段和其他字段都被 UPPER 索引。

4

2 回答 2

1

UPPER() 和 BINARY_CI 可能产生相同的结果，但 Oracle 不能互换使用它们。要使用索引和 BINARY_CI，您必须创建如下索引：

create index src_nlssort_index on src(nlssort(b, 'nls_sort=''BINARY_CI'''));

样本表和混合案例数据

create table src(b varchar2(100) not null);
insert into src select 'MiXeD CAse '||level from dual connect by level <= 100000;

默认情况下，upper() 谓词可以对 upper() 索引执行范围扫描

create index src_upper_index on src(upper(b));

explain plan for
select * from src where upper(b) = 'MIXED CASE 1';

select * from table(dbms_xplan.display(format => '-rows -bytes -cost -predicate 
    -note'));

Plan hash value: 1533361696

------------------------------------------------------------------
| Id  | Operation                   | Name            | Time     |
------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 | 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| SRC             | 00:00:01 |
|   2 |   INDEX RANGE SCAN          | SRC_UPPER_INDEX | 00:00:01 |
------------------------------------------------------------------

BINARY_CI 和 LINGUISTIC 不会使用索引

alter session set nls_sort='binary_ci';
alter session set nls_comp='linguistic';

explain plan for
select * from src where b = 'MIXED CASE 1';

select * from table(dbms_xplan.display(format => '-rows -bytes -cost -note'));

Plan hash value: 3368256651

---------------------------------------------
| Id  | Operation         | Name | Time     |
---------------------------------------------
|   0 | SELECT STATEMENT  |      | 00:00:02 |
|*  1 |  TABLE ACCESS FULL| SRC  | 00:00:02 |
---------------------------------------------

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

   1 - filter(NLSSORT("B",'nls_sort=''BINARY_CI''')=HEXTORAW('6D69786564
              2063617365203100') )

NLSSORT() 上基于函数的索引启用索引范围扫描

create index src_nlssort_index on src(nlssort(b, 'nls_sort=''BINARY_CI'''));

explain plan for
select * from src where b = 'MIXED CASE 1';

select * from table(dbms_xplan.display(format => '-rows -bytes -cost -note'));

Plan hash value: 478278159

--------------------------------------------------------------------
| Id  | Operation                   | Name              | Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                   | 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| SRC               | 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | SRC_NLSSORT_INDEX | 00:00:01 |
--------------------------------------------------------------------

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

   2 - access(NLSSORT("B",'nls_sort=''BINARY_CI''')=HEXTORAW('6D69786564
              2063617365203100') )
于 2013-09-13T16:51:12.070 回答
1

我调查并发现参数 NLS_COMP y NLS_SORT 可能会影响 oracle 如何使用字符串的执行计划（在比较或排序时）。

不需要更改 NLS 会话。添加

ORDER BY NLSSORT(column , 'NLS_SORT=BINARY_CI')

并且为 NLS 添加索引就足够了

create index column_index_binary as NLSSORT(column , 'NLS_SORT=BINARY_CI')

我在这个问题上找到了一个问题的线索，所以我正在偿还。

为什么 oracle 存储过程的执行时间会随着执行方式的不同而大大增加？

于 2017-02-24T00:25:26.740 回答