sql 優化的 分類早就有了， 就是碰不到 優化的典型例子， 今天遇到乙個.......
頁面上面的sql ：
select count(*)
from taba.npai, dm_area da
where npai.local_area_id = 3
and npai.area_id = da.area_id
第一次跑 65s 讓人忍受不了
簡單看下執行計畫， 忘記搞出來了， 大致知道內容。 taba 的local_area_id 表作為 list 分割槽， 分割槽中大概有 2千萬資料， 看了乙個 segements 大概 2.5g好像。
謂詞過濾條件為 da.area_id ， 大概91 條資料， 主要 dm_area 的影響， dm_area 表正好為 參數列， area_id 對應一條資料，
於是優化sql 思路有了，考察了 area_id 列， 發現最適合建的索引 create bitmap index idx_area_id on tab (area_id,0) local;
select /*+ index(npai, idx_area_id) */ count(1) from taba npai, dm_area da
where npai.local_area_id = 3 and npai.area_id = da.area_id ---- 結果好像是 5秒
一看還有地方 可以改進
select /*+ index(npai, idx_area_id) */ count(1) from taba npai where npai.local_area_id = 3
and exists ( select 1 from dm_area da where npai.area_id = da.area_id); --- 0.017s
最終定型
分割槽表 分割槽索引2 再談
分割槽應用 一般一張表超過2g的大小，oracle是推薦使用分割槽表的。分割槽一般都需要建立索引，說到分割槽索引，就可以分為 全域性索引 分割槽索引，即 global索引和local索引。前者並不對索引進行分割槽 索引也是表結構，索引大了也需要分割槽 而全域性索引可修飾為分割槽索引 我的理解是 分割...
優化案例 分割槽表場景下的SQL優化
有個表做了分割槽，每天乙個分割槽。該錶上有個查詢，經常只查詢表中某一天資料，但每次都幾乎要掃瞄整個分割槽的所有資料，有什麼辦法進行優化嗎？有乙個大表，每天產生的資料量約100萬，所以就採用表分割槽方案，每天乙個分割槽。下面是該錶的ddl create table t1 id bigint 20 no...
MySQL分割槽表與索引
一 定義 簡而言之就是將一張邏輯上仍然完整的表，在物理儲存的過程中,將表上的資料按某種指定的劃分依據，在物理上存放到多個 表空間 物理檔案上 這樣查詢資料時，不至於每次都掃瞄整張表而只是從當前的分割槽查到所要的資料，這樣大大提高了資料查詢的速度。優點 缺點 二 分割槽表的原理 其實對儲存引擎來說，底...