在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';
名称
-----------------------------------------
A
a
执行计划
------------------------------------ ----------------------
计划哈希值:242883967
----------------- -------------------------------------------------- ----------------------------------
|身份证 |运营|名称 |行|字节|成本(%CPU)|时间|
-------------------------------------------------------- -----------------------------------------------------------
| 0 |选择语句 | | 1 | 17 | 17 2 (0)| 00:00:01 |
| 1 |按索引 ROWID 访问表| T | 1 | 17 | 17 2 (0)| 00:00:01 |
|* 2 |指数范围扫描 | IND_T_L_NAME | 1 | | 1 (0)| 00:00:01 |
---------------------------------------------------- -------------------------------------------------- -
谓词信息(通过操作id标识):
------------------------------------------------ -----------------
2 - 访问(NLSSORT("NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('6100') )
注意
-----
-用于此语句的动态采样

ACID属性包括原子性、一致性、隔离性和持久性,是数据库设计的基石。1.原子性确保事务要么完全成功,要么完全失败。2.一致性保证数据库在事务前后保持一致状态。3.隔离性确保事务之间互不干扰。4.持久性确保事务提交后数据永久保存。

MySQL既是数据库管理系统(DBMS),也与编程语言紧密相关。1)作为DBMS,MySQL用于存储、组织和检索数据,优化索引可提高查询性能。2)通过SQL与编程语言结合,嵌入在如Python中,使用ORM工具如SQLAlchemy可简化操作。3)性能优化包括索引、查询、缓存、分库分表和事务管理。

MySQL使用SQL命令管理数据。1.基本命令包括SELECT、INSERT、UPDATE和DELETE。2.高级用法涉及JOIN、子查询和聚合函数。3.常见错误有语法、逻辑和性能问题。4.优化技巧包括使用索引、避免SELECT*和使用LIMIT。

MySQL是一种高效的关系型数据库管理系统,适用于存储和管理数据。其优势包括高性能查询、灵活的事务处理和丰富的数据类型。实际应用中,MySQL常用于电商平台、社交网络和内容管理系统,但需注意性能优化、数据安全和扩展性。

SQL和MySQL的关系是标准语言与具体实现的关系。1.SQL是用于管理和操作关系数据库的标准语言,允许进行数据的增、删、改、查。2.MySQL是一个具体的数据库管理系统,使用SQL作为其操作语言,并提供高效的数据存储和管理。

InnoDB使用redologs和undologs确保数据一致性和可靠性。1.redologs记录数据页修改,确保崩溃恢复和事务持久性。2.undologs记录数据原始值,支持事务回滚和MVCC。

EXPLAIN命令的关键指标包括type、key、rows和Extra。1)type反映查询的访问类型,值越高效率越高,如const优于ALL。2)key显示使用的索引,NULL表示无索引。3)rows预估扫描行数,影响查询性能。4)Extra提供额外信息,如Usingfilesort提示需要优化。

Usingtemporary在MySQL查询中表示需要创建临时表,常见于使用DISTINCT、GROUPBY或非索引列的ORDERBY。可以通过优化索引和重写查询避免其出现,提升查询性能。具体来说,Usingtemporary出现在EXPLAIN输出中时,意味着MySQL需要创建临时表来处理查询。这通常发生在以下情况:1)使用DISTINCT或GROUPBY时进行去重或分组;2)ORDERBY包含非索引列时进行排序;3)使用复杂的子查询或联接操作。优化方法包括:1)为ORDERBY和GROUPB


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

适用于 Eclipse 的 SAP NetWeaver 服务器适配器
将Eclipse与SAP NetWeaver应用服务器集成。

Dreamweaver CS6
视觉化网页开发工具

禅工作室 13.0.1
功能强大的PHP集成开发环境

EditPlus 中文破解版
体积小,语法高亮,不支持代码提示功能

MinGW - 适用于 Windows 的极简 GNU
这个项目正在迁移到osdn.net/projects/mingw的过程中,你可以继续在那里关注我们。MinGW:GNU编译器集合(GCC)的本地Windows移植版本,可自由分发的导入库和用于构建本地Windows应用程序的头文件;包括对MSVC运行时的扩展,以支持C99功能。MinGW的所有软件都可以在64位Windows平台上运行。