Oracle jdbc瘦客户端-不使用varchar2的唯一索引



首先是一些基础知识。

Java 6OJDBC6Oracle 10.2.0.4 (11g版本也有相同的结果)

我正在经历sql语句在Java中使用OJDBC6客户端和使用可能使用本机/OCI驱动程序的sql Gate工具执行时的行为不同。由于某种原因,优化器选择对Java中执行的语句使用哈希连接,而不是对其他语句使用哈希连接。

表格如下:

CREATE TABLE DPOWNERA.XXX_CHIP (
   xxxCH_ID        NUMBER(22)       NOT NULL, 
   xxxCHP_ID       NUMBER(22)       NOT NULL, 
   xxxSP_ID        NUMBER(22)           NULL, 
   xxxCU_ID        NUMBER(22)           NULL, 
   xxxFT_ID        NUMBER(22)           NULL, 
   UEMTE_ID        NUMBER(38)           NULL, 
   xxxCH_CHIPID    VARCHAR2(30)     NOT NULL
)

指数:

ALTER TABLE DPOWNERA.XXX_CHIP ADD
  (
     CONSTRAINT IX_AK1_XXX_CHIPV2
     UNIQUE ( XXXCH_CHIPID )
     USING INDEX
     TABLESPACE DP_DATA01 
     PCTFREE 10
     INITRANS 2
     MAXTRANS 255
     STORAGE (
        INITIAL 128 K
        NEXT 128 K
        MINEXTENTS 1
        MAXEXTENTS UNLIMITED
    )
);
下面是我使用的SQL:

SELECT *
    FROM   (SELECT m2.*,
            rownum rnum
            FROM   (SELECT m_chip.xxxch_id,
                      m_chip.xxxch_chipid
                      FROM   xxx_chip m_chip
                      ORDER  BY m_chip.xxxch_chipid) m2
            WHERE  rownum < 101)
WHERE  rnum >= 1; 

最后是解释计划的节选:

SQL Tool Query:

OPERATION        OBJECT_NAME         COST  CARDINALITY CPU_COST
---------------- ------------------- ----- ----------- ----------
SELECT STATEMENT NULL                    2          10      11740
VIEW             NULL                    2          10      11740
COUNT            NULL                 NULL        NULL       NULL
VIEW             NULL                    2          10      11740
NESTED LOOPS     NULL                    2          10      11740
TABLE ACCESS     XXX_CHIP                1     1000000       3319
INDEX            IX_AK1_XXX_CHIPV2       1          10       2336
TABLE ACCESS     XXX_CUSTOMER            1           1        842
INDEX            IX_PK_XXX_CUSTOMER      1           1        105

QQL Java查询OJDBC瘦客户端:

**OPERATION        OBJECT_NAME         COST  CARDINALITY CPU_COST**
SELECT STATEMENT NULL                15100         100 1538329415
VIEW             NULL                15100         100 1538329415
COUNT            NULL                 NULL        NULL       NULL
VIEW             NULL                15100     1000000 1538329415
SORT             NULL                15100     1000000 1538329415
HASH JOIN        NULL                 1639     1000000  424719850
VIEW             index$_join$_004        3           3    2268646
HASH JOIN        NULL                 NULL        NULL       NULL
INDEX            IX_AK1_XXX_CUSTOMER     1           3        965
INDEX            IX_PK_XXX_CUSTOMER      1           3        965
TABLE ACCESS     xxx_CHIP             1614     1000000  320184788

所以,我失去了为什么哈希连接是由优化器选择的?我的猜测是varchar2的处理方式不同。

我找到了一个答案,它比我想象的要简单。这都与索引列的VARCHAR2数据类型有关。我的数据库被设置为语言和国家"en","US",但在本地我有另一种语言和地区。因此,优化器正确地丢弃了索引,因为它没有配置与客户端相同的语言和国家。

所以我所做的测试是在eclipse.ini文件中输入一些额外的-D参数来启动eclipse。

-Duser.language=en
-Duser.country=US
-Duser.region=US

然后在Eclipse的数据源资源管理器中,我创建了一个连接并运行了我的语句,它运行得非常好。

因此,我们学到的教训是始终确保客户端和数据库在语言方面是兼容的。也许我们会改变,所以我们在数据库中使用UTF-8,这样每次安装都是一样的。否则,您将不得不根据国家和语言为每个安装配置它。

希望这将帮助某人。如果答案不清楚,请发表评论。

相关内容

  • 没有找到相关文章

最新更新