NLS_SORT和NLS_COMP是Oracle兩個初始化參數。顧名思義，NLS_SORT和NLS_COMP是設置排序和比較的方式。通過設置這兩個參數可以實現自定義的排序和比較的方式。設置這兩個參數的值可以在數據庫創建的時候指定，也可以通過Alter Session語句來修改。如果是在創建數據庫的時候設定，那么是不能再修改的，并在所有的Session中起作用。但是我們也通過Alter Session命令臨時改變這兩個參數的值，在會話中臨時使用一種特定的排序和比較的方式。要改變所有的會話的排序和比較的方式，我們也可以通過修改注冊表的方式來達到目的，如果系統采用的多層體系架構，并且所有的邏輯層代碼都部署在相同的應用程序服務器（如IIS）上的。

查看會話中這兩個參數值，我們可以使用如下的查詢語句：

select * from NLS_SESSION_PARAMETERS;?

PARAMETER???????????????????????????????????????????????????? VALUE?
------------------------------------------------------------ --------------------------------------------------------------------------------?
NLS_LANGUAGE????????????????????????????????????????????????? SIMPLIFIED CHINESE?
NLS_TERRITORY???????????????????????????????????????????????? CHINA?
NLS_CURRENCY????????????????????????????????????????????????? RMB?
NLS_ISO_CURRENCY????????????????????????????????????????????? CHINA?
NLS_NUMERIC_CHARACTERS??????????????????????????????????????? .,?
NLS_CALENDAR????????????????????????????????????????????????? GREGORIAN?
NLS_DATE_FORMAT?????????????????????????????????????????????? DD-MON-RR?
NLS_DATE_LANGUAGE???????????????????????????????????????????? SIMPLIFIED CHINESE?
NLS_SORT????????????????????????????????????????????????????? BINARY?
NLS_TIME_FORMAT?????????????????????????????????????????????? HH.MI.SSXFF AM?
NLS_TIMESTAMP_FORMAT????????????????????????????????????????? DD-MON-RR HH.MI.SSXFF AM?
NLS_TIME_TZ_FORMAT??????????????????????????????????????????? HH.MI.SSXFF AM TZR?
NLS_TIMESTAMP_TZ_FORMAT?????????????????????????????????????? DD-MON-RR HH.MI.SSXFF AM TZR?
NLS_DUAL_CURRENCY???????????????????????????????????????????? RMB?
NLS_COMP????????????????????????????????????????????????????? BINARY?
NLS_LENGTH_SEMANTICS????????????????????????????????????????? BYTE?
NLS_NCHAR_CONV_EXCP?????????????????????????????????????????? FALSE

??? 在我們的一個項目中，客戶突然要求所有的查詢都大小寫無關，但是由于在創建數據庫的時候沒有設置兩個參數的值，在沒一個查詢語句中去執行Alter Session語句來設置這兩個值又顯得十分的笨拙和荒唐，所以我們采用修改注冊表的方式來達到這個目的，但是有一天客戶突然報告原來運行的很快的程序，突然變得特別的慢。慢的表征是用戶創建一個比較大的變更單，變更單里包含了幾千條變更記錄。從出錯的信息中我分析出是超時的原因，超時也就意味者系統長時間無法響應或者事務長時間無法完成。

??? 生產環境出錯是非常致命的。根據用戶提供的數據我們馬上做了測試，結果表明是在幾秒鐘就迅速完成了！用戶將數據導出到另外一臺測試服務器上運行，還是相同的結果，遠程指導用戶直接在測試庫上運行存儲過程，結果第二天用戶告訴我，執行完該存儲過程整整花了20多個小時！！

??? 又是一番針對存儲過程的分析和優化，針對服務器設置的各個方面的設置的分析，但是問題仍然得不到解決，百思不得其解。又是一天過去了，真讓人心焦啊。晚上在家里查找資料的時候，用戶在MSN上告訴我，問題得到解決了，我一驚，是怎么解決的？用戶告訴我，將在注冊表中修改了NLS_SORT和NLS_COMP的注冊項刪除掉，重新啟動IIS，程序運行的速度就一下子提高了，確實就是在幾秒鐘內完成的！！

在Oracle官方提高的文檔中，確實提到如果改變了NLS_SORT和NLS_COMP的缺省值，可能會對性能產生影響但是我沒有想到會有這么大的影響。在Oracle官方文檔中對NLS_SORT是這樣描述的。

NLS_SORT

PropertyDescription

Parameter type	String
Syntax	NLS_SORT = { BINARY |?linguistic_definition?}
Default value	Derived from?NLS_LANGUAGE
Modifiable	ALTER SESSION
Range of values	BINARY?or any valid linguistic definition name

NLS_SORT?specifies the collating sequence for?ORDER BY?queries.

• If the value is?BINARY, then the collating sequence for?ORDER BY?queries is based on the numeric value of characters (a binary sort that requires less system overhead).

• If the value is a named linguistic sort, sorting is based on the order of the defined linguistic sort. Most (but not all) languages supported by theNLS_LANGUAGE?parameter also support a linguistic sort with the same name.

  Note:

  Setting?NLS_SORT?to anything other than?BINARY?causes a sort to use a full table scan, regardless of the path chosen by the optimizer.?BINARY?is the exception because indexes are built according to a binary order of keys. Thus the optimizer can use an index to satisfy the?ORDER BY?clause whenNLS_SORT?is set to?BINARY. If?NLS_SORT?is set to any linguistic sort, the optimizer must include a full table scan and a full sort in the execution plan.

You must use the?NLS_SORT?operator with comparison operations if you want the linguistic sort behavior.

?

根據上文中標紅部分的注視，如果NLS_SORT不是設置為"Binary"，那么就會引起全表掃描，是不會使用索引的，在我們的系統中變更單涉及到的數據都是數據龐大的表，如果不使用到索引，查詢的效率不受到影響才怪呢！

NLS_COMP

PropertyDescription

Parameter type	String
Syntax	NLS_COMP = { BINARY | LINGUISTIC | ANSI }
Default value	BINARY
Modifiable	ALTER SESSION
Basic	No

NLS_COMP?specifies the collation behavior of the database session.

Values:

• BINARY

  Normally, comparisons in the?WHERE?clause and in PL/SQL blocks is binary unless you specify the?NLSSORT?function.

• LINGUISTIC

  Comparisons for all SQL operations in the?WHERE?clause and in PL/SQL blocks should use the linguistic sort specified in the?NLS_SORT?parameter.?To improve the performance, you can also define a linguistic index on the column for which you want linguistic comparisons.

• ANSI

  A setting of?ANSI?is for backwards compatibility; in general, you should set?NLS_COMP?to?LINGUISTIC

根據標紅的部分，要提高性能可以在需要比較的列上建立一個linguistic index。

總結

以上是生活随笔為你收集整理的小心NLS_SORT和NLS_COMP的设置成为性能杀手的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。