索引的優化

發現乙個sql執行很慢，如下：

select

*from

rmes.r_wip_tracking_t wt, cmes.c_material_t m

where

m.material_type =1

and(m.material_spec 

like'l%

'orm.material_spec 

like'c%

')andwt.model_id 

=m.material_id      

andwt.sn 

>=

'1073h2h72270002

'andwt.sn 

<=

'1073h2h72270002

'計畫分析後，發現是都有走索引。

統計兩個表如下：

1.r_wip_tracking_t: 總共有3580030記錄，其中用sn有索引，並且sn在表中唯一

2.c_material_t 總共有512條資料，material_type是外來鍵有normal索引，material_spec無索引

有一點發現，如果去掉material_type＝1的sql會變很快，說明是material_type的問題

在512記錄中發現

material_type

count

0 196

1 276

2 8

3 10

4 8

5 13

7 1

說明material_type索引型別錯了，需要改成bitmap型

執行：drop index fk_type;

create bitmap index fk_type on c_material_t (material_type) tablespace cmes;

就把sql的執行時間從89秒降低到了0.15秒

索引的優化

1 max 對於max取某一列最大值的時候，優化方案就是建立索引，然後倒敘排列然後取第乙個 2 count 和 count id 的區別 如果某一列存在null的話，那麼null的行將不被統計。例如有id和name兩列，有100行資料 count 為100 count name 為98，兩行null...

理解索引 索引優化

最近有個需求，要修改現有儲存結構，涉及查詢條件和查詢效率的考量，看了幾篇索引和hbase相關的文章，回憶了相關知識，結合專案需求，說說自己的理解和總結。索引結構和資料定位過程 查詢過程和高階查詢 執行計畫詳細介紹 常見優化方法 聯合索引最左字首原則 復合索引遵守 最左字首 原則，查詢條件中，使用了復...

理解索引 索引優化

最近有個需求，要修改現有儲存結構，涉及查詢條件和查詢效率的考量，看了幾篇索引和hbase相關的文章，回憶了相關知識，結合專案需求，說說自己的理解和總結。索引結構和資料定位過程 查詢過程和高階查詢 執行計畫詳細介紹 常見優化方法 聯合索引最左字首原則 復合索引遵守 最左字首 原則，查詢條件中，使用了復...