Nvarchar數據類型比較特殊

有開發人員反饋，兩個字段關聯，一個是varchar、另外一個是Nvarchar，會有性能問題嗎？

這個問題其實不能說一定有。通過實驗來說明吧。

具體實驗-表結構

• A表的VAR列、NVAR列和B表的NVAR列和M列有索引
• B表的VAR列索引不可見（或者說沒有索引）

類型轉換

• VAR列有索引，但是是字符型，給了一個數值。函數轉換了，全表掃描
• 在執行計劃中也看到了TO_NUMBER(“VAR”)=1的字樣

兩種類型都有索引情況下

• VAR列有索引，所以用到了索引。
• NVAR列有索引，所以用到了索引。
• 但是注意NVAR類型列的時候有一個(“NVAR”=U’1’) U。而Var的類型時候沒有。

B表VAR關閉索引

• XXG@xxg> alter index b_var invisible;

索引已更改。

• 設置B表var列索引不可見。自然是全表查詢。
  

• B表的M列搜索引，可以使用。

• 

那么B表通過m列找到的數據傳導給A表

• 可以用到索引的。即使b.var的索引不可見。相當于b.m='1’找到了b.var=‘1’ select * from a,b where a.var=‘1’ and b.m=‘1’;

• 所以關聯列在特殊情況下，不是必須兩列都有索引。但是這是特殊情況。一般日常中我還是建議，且強制關聯列都建立索引。因為我們無法保證都是B表這種作為傳導條件的。如果是A表作為傳導入口就不行了。

• 因為在b.var沒有索引的情況下。無論執行下面哪種B表都是全表。

• 

在B表nvar有索引的情況下，看看索引的使用情況

• B表nvar有索引的情況下，這個是可以用到索引的。

• 

• 但是只要一關聯到A表的VAR列就是全表關聯了。

• 

• 那么在其他不變的情況下，而如果是A表的VAR作為傳導開始，也是可以都用到索引的。

• 

• 所以這就要求如果兩個關聯列一個是var一個是Nvar的話，那么要以var的作為條件去查比較好。

• 從nvar傳到var即使a.var列有索引還是發生了轉換

• 

從var傳到nvar即使b.var列現在索引是不可見的，兩個表都用到了索引。

結論

• 最好是類型一樣
• 數據庫設計由DBA負責而不是開發人員
• 如果可能的話，改成varchar。避免使用varchar
• 最好關聯列都建立索引
• 實在不行的話，用var列的條作為入口查詢條件。