Oracle数据库中执行的SQL，很多时候会因为种种原因产生多个不同的执行版本，一个游标的版本过多很容易引起数据库的性能问题，甚至故障。
有时候一个SQL的版本数量可能多达数万个，以下是我之前在"云和恩墨大讲堂”分享过的一个案例。这个报告中的 SQL，最高达到了26万个 SQL 版本。算是我见过的“之最”之一。
产生SQL多版本的原因很多，通过如下的一些测试我们可以稍微来看看如何分析和找到可能的原因。
以下作为一个基础测试数据，一条基本的SQL查询：
create table t1(c1 int, c2 nvarchar2(100));
alter system flush shared_pool;
var b1 number;
var b2 varchar2(10);
exec :b1 := 1;
exec :b2 := '0';
select /* test */ * from t1 where c1 = :b1 and c2 = :b2 order by c2;
如果我们修改了优化器参数、环境变量、绑定变量等，都可能使得SQL发生重新解析，产生不同的子游标，也就是不同的VERSION。
Rem 这里我们修改了NLS_SORT参数，
Rem 再来查看SQL的游标数。
SQL> alter session set nls_sort = 'SCHINESE_RADICAL_M'; Session altered.
REM 注意，以上第一个Child就是因为
REM 语言不匹配产生的（LANGUAGE_MISMATCH）
REM 以下修改了优化器模式，
REM 又一个新的子游标将会因此而产生。
REM 可以看到，第二个子游标是因为优化器
REM 模式不匹配产生的，OPTIMIZER_MODE_MISMATCH.
REM 以下步骤，我们绑定了不同长度的绑定变量，
REM 由此又可能产生新的SQL版本。
REM 我们看到的第三个子游标就是
REM 因为绑定变量长度不同而产生的。
从Oracle 9i开始，Oracle对中文语言方式（Simplified Chinese和Traditional Chinese）提供了多种排序方式。主要由以下四种，大家可以进行修改尝试：
SCHINESE_RADICAL_M 针对简体中文，按照部首（第一顺序）、笔划（第二顺序）排序
SCHINESE_STROKE_M 针对简体中文，按照笔划（第一顺序）、部首（第二顺序）排序
SCHINESE_PINYIN_M 针对简体中文，按照拼音排序
TCHINESE_RADICAL_M 针对繁体中文，按照部首（第一顺序）、笔划（第二顺序）排序
TCHINESE_STROKE_M 针对繁体中文，按照笔划（第一顺序）、部首（第二顺序）排序
当然可以逐一尝试：
以上测试是基于11.2.0.3版本，在Oracle 12c中，相关的可能因素已经多达64个，参考官方手册可以了解 V$SQL_SHARED_CURSOR 的更详细信息。
本文出自数据和云公众号，原文链接
