個人總結幾點：
1、驅動表中的索引要將區間字段（sendtime之類）放到固定值（orgid等）的後面
2、驅動表的連線字段可以放在索引最後，以避免讀取rowid
3、連線表的連線欄位要放在索引最前面。
舉個例子：
select
count
(*)as
col_0_0_
from
rec_bankinstruction batchrecba0_
cross
join
rec_bill_detail batchrecbi1_
where
batchrecbi1_.id=batchrecba0_.billdetailid
andbatchrecba0_.orgid=batchrecbi1_.orgid
andbatchrecba0_.status= :1
andbatchrecba0_.orgid= :2
andbatchrecba0_.sendtime>= :3
執行計畫：
現有索引結構：
索引優化：
drop
index
rec_bank_query_index;
create
index
rec_bank_query_indexon
rec_bankinstruction(orgid,sendtime,createtime,status,billdetailid);
drop
index
rec_bill_orgid;
create
index
rec_bill_orgidon
rec_bill_detail(orgid,importdate,
id);
優化之後執行計畫：
優化之後索引結構：
以上並沒有考慮索引欄位的順序問題
但是，sql是從rec_bankinstructionloop到rec_bill_detail
所以，首先應確定rec_bankinstruction的索引，應該是status\orgid\sendtime三個字段，然後把billdetailid包含進來
第乙個索引存在兩個問題：
1、sendtime應該往後放，這樣索引資料將會聚集，減少io。如果sendtime往前放，那麼status不是索引，而是篩選，io增大
建議順序為orgid\status\sendtime，至於createtime可以放著，是用於篩選的，當前沒有用到
2、rec_bill_detail
是通過orgid\id關聯的，那麼這兩個字段必須放前面，如你現在索引，則id變成了篩選，而非索引
建議順序orgid\id\importdate，importdate是包含字段，可以用於篩選，可以用於顯示
因此，先對rec_bill_detail
的索引順序更改：
drop
index
rec_bill_orgid;
create
index
rec_bill_orgidon
rec_bill_detail(orgid,
id,importdate);
更改後索引為：
執行計畫為：
可以看到對rec_bill_detail
的join查詢有了明顯提高。
再更新rec_bankinstruction表的索引：
drop
index
rec_bank_query_index;
create
index
rec_bank_query_indexon
rec_bankinstruction(orgid,status,sendtime,createtime,billdetailid);
索引為：
執行計畫為：
instruction表的掃瞄有了明顯提高。
索引對查詢效率的影響
我們將利用advanturewords2008r2中的sales.salesorderdetail表，其中有12萬條資料，非常適合用於測試。不過我們不直接在這張表上做測試，因為這張表上已經有索引了。我們需要新建一張表，將該表中的資料匯入我們新建的test和test2表。test和test2的建立方法...
SQL組合查詢及先後順序對效率的影響
在sql跨表組合查詢存在效率問題，舉例比如 delete from media source where movie id in select media id from media where type 2 and origin 3 和delete from media source where ...
mysql 索引長度對索引的影響
1 查詢頻繁 2 區分度高 3 長度小 4 盡量能覆蓋常用查詢欄位.1 索引長度直接影響索引檔案的大小,影響增刪改的速度,並間接影響查詢速度 占用記憶體多 針對列中的值,從左往右擷取部分,來建索引 1 截的越短,重複度越高,區分度越小,索引效果越不好 2 截的越長,重複度越低,區分度越高,索引效果越...