資料庫規範之SQL規範寫法

1.原始sql
改寫之後
改寫到這裡，是不是結束了呢？不是，看一下索引，發現在state欄位有個btree索引。不當的索引，拖慢查詢。刪除掉

RIGHT(trade_serial_no, 5) % '15' = '3' 無法使用索引。t_chk_plat_bill有203萬資料，建議加索引在batch_no上面。



附上索引知識

BTree索引

BTree（多路搜尋樹，並不是二叉的）是一種常見的資料結構。

不適合：

• 單列索引的列不能包含null的記錄，複合索引的各個列不能包含同時為null的記錄，否則會全表掃描；索引失效很多時候是因為這列有null，空值
  
• 不適合鍵值較少的列（重複資料較多的列）；假如你建立了，會發生什麼情況呢？查詢反而會變慢
  
• 前導模糊查詢不能利用索引(like '%XX'或者like '%XX%')，該類sql語句導致索引失效
  

Hash雜湊索引

Hash雜湊索引是根據HASH演算法來構建的索引。

適合：

• 精確查詢非常快（包括= <> 和in），其檢索效率非常高，索引的檢索可以一次定位，不像BTree 索引需要從根節點到枝節點，所以 Hash 索引的查詢效率要遠高於 B-Tree 索引。

不適合：

• 不適合模糊查詢和範圍查詢（包括like，>，<，between……and等），由於 Hash 索引比較的是進行 Hash 運算之後的 Hash 值，所以它只能用於等值的過濾，不能用於基於範圍的過濾，因為經過相應的 Hash 演算法處理之後的 Hash 值的大小關係，並不能保證和Hash運算前完全一樣；
• 不適合排序，資料庫無法利用索引的資料來提升排序效能，同樣是因為Hash值的大小不確定；
• 複合索引不能利用部分索引欄位查詢，Hash 索引在計算 Hash 值的時候是組合索引鍵合併後再一起計算 Hash 值，而不是單獨計算 Hash 值，所以透過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash 索引也無法被利用。
• 同樣不適合鍵值較少的列（重複值較多的列）；

Bitmap點陣圖索引

 就是用點陣圖表示的索引，對列的每個鍵值建立一個點陣圖。相對於BTree索引，佔用的空間非常小，建立和使用非常快。點陣圖索引由於只儲存鍵值的起止Rowid和點陣圖,佔用的空間非常少。

適合

• 適合決策支援系統；
• 當select count(XX) 時,可以直接訪問索引中一個點陣圖就快速得出統計資料；
• 當根據鍵值做and，or或 in(x,y,..)查詢時，直接用索引的點陣圖進行或運算,快速得出結果行資料。

不適合

• 不適合鍵值較多的列（重複值較少的列）；
• 不適合update、insert、delete頻繁的列，代價很高。到底是什麼代價呢？update,insert,delete的時候會鎖住鍵值一樣的行。