資料型別與函式索引-Oracle篇

上篇是MySQL的這篇是Oracle的。總體來說差不多，不一樣的地方我會標出來。

先建立一個表，寫入10條資料。 （MySQL5條就行，Oracle10條其實都不行。原因是Oracle處理覺得10條資料有沒有索引一樣。所以我最後是寫入了1萬條資料）

分別建立索引

同時把T表也建立好。完全和MySQL場景一樣。

然後為了更好的體現，對兩個表都收集一下統計資訊。

接下來看結果。a列是數值型的用到索引。

a列是數值型的，遇到字元自動轉換了。

B列是字元型的，只能是字元型才能用到索引。

B列是字元型的，數值型的不能用到索引。

C列是小數型的，照搬數值型規則。都是可以的。

D列是時間，用時間的寫法。

如果用字串，執行計劃可以，但是實際執行是報錯的。

接下來，沒有條件的關聯。兩個全表。不過由於兩個列有一個是索引列（T表的ID列故意不是），不至於笛卡爾積。cost不大。

當有索引列帶上索引，立刻看到只找一行，相對來說總的cost變化小了大約一半。

條件從w.id換成t.id，驗證最佳化器的SQL改寫。與MySQL一樣。（下一次看PG的估計也是一樣，這是基本邏輯）

都是索引列且型別匹配情況下：效果很好。

當關聯列資料型別不匹配時候：就和沒建立索引是一樣的效果了。

如果型別差距較大，直接報錯。

繼續：w.b是字元型，w.b和t.c關聯。 t.c是小數型別。儘管不匹配但是最終cost和匹配的幾乎一樣。這裡Oracle處理的比MySQL好。

w.c是小數型，w.c和t.b關聯。 t.b是字元型別。條件是w.b字元型。關聯列不匹配，導致一個表全表。

最後看看型別轉換。w.a是數值型，一旦轉換（在等號左邊轉換）就是全表，索引失效。

在T表上給A建立一個函式索引。所以在T表上用同樣的語句，則用到了索引T22.

解決問題的思路就是讓資料型別匹配。大概不匹配時候如下：

改成這樣就可以了。雖然這不是推薦的，但是已經型別不對的場景下的下下策。上上策還是表的型別要選擇對。