在Oracle中进行大小写不敏感的查询
在Oracle中,命令和对象名称都是大小写不敏感的,因为Oracle在处理语句时,将所有的名称和命令全部转化为大写。但是对于字符串中
在Oracle中,命令和对象名称都是大小写不敏感的,因为Oracle在处理语句时,将所有的名称和命令全部转化为大写。
但是对于字符串中的字符,无论是比较还是排序,都是大小写敏感的。这在Oracle是默认方式,但不是唯一的方式。
下面看一个简单的例子:
SQL> CREATE TABLE T (NAME VARCHAR2(30));
表已创建。
SQL> INSERT INTO T VALUES ('A');
已创建 1 行。
SQL> INSERT INTO T VALUES ('a');
已创建 1 行。
SQL> INSERT INTO T VALUES ('B');
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> CREATE INDEX IND_T_NAME ON T(NAME);
索引已创建。
看一下默认情况下的排序和查询结果:
SQL> SELECT * FROM T ORDER BY NAME;
NAME
------------------------------
A
B
a
SQL> SELECT * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
这是最正常不过的结果了,下面修改会话默认的排序方式:
SQL> ALTER SESSION SET NLS_SORT = BINARY_CI;
会话已更改。
SQL> SELECT * FROM T ORDER BY NAME;
NAME
------------------------------
A
a
B
SQL> SELECT * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
可以看到,通过设置排序方法为BINARY_CI,已经实现了对排序的大小写不敏感,但是查询语句中仍然是大小写敏感的,下面进一步修改比较方式:
SQL> ALTER SESSION SET NLS_COMP = LINGUISTIC;
会话已更改。
SQL> SELECT * FROM T ORDER BY NAME;
NAME
------------------------------
A
a
B
SQL> SELECT * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
a
现在已经达到了大小写不敏感查询的目的了,这是由于设置比较方式是基于语义的,而不是基于二进制的,而语言方式下A和a是没有区别的。
虽然目的达到了,但是还是要说明一下,,这里虽然实现了对大小写不敏感的查询,但是这个结果的实现与表面看到的现象并不完全相同。
从查询语句上看,似乎只是对NAME进行一下判断就可以了,并未对列进行任何的操作,而实际上并非如此,下面看看这种情况下的执行计划:
SQL> SET AUTOT ON EXP
SQL> SELECT * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
a
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 17 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 1 | 17 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(NLSSORT("NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('6100')
)
Note
-----
- dynamic sampling used for this statement
Oracle居然对列进行了操作,将NAME进行了NLSSORT操作,然后判断是否与目标值进行判断。不过Oracle也没有其他的好方法进行处理,对等号右边的常量进行转换固然代价较低,但是SQL的判断条件就由等于变成了IN,这种转换恐怕变化更大。而且还要找到所有其他所有可能转换为目标值的常量,这个操作要比对列进行转换复杂得多。
不过这种方法就存在一个问题,就是Oracle无法使用索引了,一方面是由于对列进行了操作,另一方面是由于Oracle的索引是按照BINARY方式编码存储的。因此这种查询会采用全表扫描的方式。
SQL> SELECT /*+ INDEX(T IND_T_NAME) */ * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
a
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 17 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 1 | 17 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(NLSSORT("NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('6100')
)
Note
-----
- dynamic sampling used for this statement
这个情况,可以考虑建立一个函数索引来解决问题:
SQL> CREATE INDEX IND_T_L_NAME ON T(NLSSORT(NAME, 'NLS_SORT=BINARY_CI'));
索引已创建。
SQL> SELECT * FROM T WHERE NAME = 'A';
NAME
------------------------------
A
a
执行计划
----------------------------------------------------------
Plan hash value: 242883967
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 17 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 17 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IND_T_L_NAME | 1 | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access(NLSSORT("NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('6100') )
Note
-----
- dynamic sampling used for this statement

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.

이 기사에서는 Drop Table 문을 사용하여 MySQL에서 테이블을 떨어 뜨리는 것에 대해 설명하여 예방 조치와 위험을 강조합니다. 백업 없이는 행동이 돌이킬 수 없으며 복구 방법 및 잠재적 생산 환경 위험을 상세하게합니다.

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

기사는 외국 열쇠를 사용하여 데이터베이스의 관계를 나타내고 모범 사례, 데이터 무결성 및 피할 수있는 일반적인 함정에 중점을 둡니다.

이 기사에서는 PostgreSQL, MySQL 및 MongoDB와 같은 다양한 데이터베이스에서 JSON 열에서 인덱스를 작성하여 쿼리 성능을 향상시킵니다. 특정 JSON 경로를 인덱싱하는 구문 및 이점을 설명하고 지원되는 데이터베이스 시스템을 나열합니다.
