sql語句相關

drop、truncate和delete的區別

  • 從速度上來說,drop> truncate(截短) > delete。
  • 從表和索引所佔空間來說
    • 表被truncate 後,這個表和索引所佔用的空間會恢復到初始大小,
    • delete操作不會減少表或索引所佔用的空間。
    • drop語句將表所佔用的空間全釋放掉。
  • 從應用範圍來說
    • drop 可以針對數據庫和table
    • truncate 只能對table
    • delete可以是table和view
  • delete語句執行刪除的過程是每次從表中刪除一行,並且同時將該行的刪除操作作爲事務記錄在日誌中保存以便進行進行回滾操作。 truncate table則一次性地從表中刪除所有的數據並不把單獨的刪除操作記錄記入日誌保存,刪除行是不能恢復的。並且在刪除的過程中不會激活與表有關的刪除觸發器,執行速度快。

having與where的區別

聚合函數與分組group by是比較where、having 的關鍵。

  • 若引入聚合函數來對group by 結果進行過濾(對分組過濾)則只能用having。而where只過濾行。

分頁語句Limit用法

  • limit的用法
mysql> SELECT * FROM table LIMIT 5,10; // 檢索記錄行 6-15  
 
mysql> SELECT * FROM table LIMIT 95,-1; // 檢索記錄行 96-last.  

mysql> SELECT * FROM table LIMIT 5; //檢索前 5 個記錄行  

  • 分頁查詢
//在中小數據量的情況下,使用最簡單的sql就可以,需要注意的問題是確保使用了索引,如果實際SQL類似下面語句,那麼在category_id, id兩列上建立複合索引比較好
SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 50, 10

//隨着數據量的增加,頁數會越來越多,查看後幾頁的SQL就可能類似:
SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 10000, 10

//一言以蔽之,就是越往後分頁,LIMIT語句的偏移量就會越大,速度也會明顯變慢。此時,我們可以通過子查詢的方式來提高分頁效率,大致如下:
SELECT * FROM articles WHERE category_id = 123 AND id >=
 (SELECT id FROM articles  WHERE category_id = 123 ORDER BY id LIMIT 10000, 1) LIMIT 10

好文連接:https://www.cnblogs.com/youyoui/p/7851007.html

  • 爲什麼使用子查詢快?因爲子查詢是在索引上完成的,而普通的查詢是在數據文件上完成的,通常來說,索引文件要比數據文件小得多,所以操作起來也會更有效率。實際可以利用類似策略模式的方式去處理分頁,比如判斷如果是一百頁以內,就使用最基本的分頁方式,大於一百頁,則使用子查詢的分頁方式。

聯表查詢方式

聯表公式

查詢例子:

------右聯結例子------
select distinct fang.org_code as entity_id,
    'uc_org_code_not8' as type,
    ${-1d_yyyyMMdd} as day FROM
(select distinct org_level8_code from dw.dw_hr_org_da where pt='${-1d_pt}') uc
right join
(select distinct org_code from ods.ods_myth_division_org_resblock_score_da where pt='${-1d_pt}') fang
on uc.org_level8_code = fang.org_code
where uc.org_level8_code is null

------三表查詢例子------
select distinct concat(fang.org_code, '+', fang.resblock_id) as entity_id,
    'div_is_real_maintain' as type,
    ${-1d_yyyyMMdd} as day FROM
(select distinct org_code, resblock_id from ods.ods_group_build where pt='${-1d_pt}' and div_type = '101000000002'
union
select distinct org_code, resblock_id from ods.ods_alliance_division_group_div_da where pt='${-1d_pt}' and div_type = 1) division
inner join
(select distinct org_code, resblock_id from ods.ods_myth_division_org_resblock_score_da where pt='${-1d_pt}' and is_real_maintain = 1) fang
on division.org_code = fang.org_code and division.resblock_id = fang.resblock_id
where division.org_code = null

------三表聯結+group by用法------
select distinct concat(myth.org_code, '+', myth.resblock_id) as entity_id,
    'housedel_num' as type,
    ${-1d_yyyyMMdd} as day FROM
(select distinct org_code, resblock_id, housedel_num from ods.ods_myth_division_org_resblock_score_da where pt='${-1d_pt}') myth
inner join

(select role.org_code, dele.resblock_id, count(*) as housedel_num from
(select housedel_code, org_code from ods.ods_house_sh_housedel_role_da where pt='${-1d_pt}' and role_status = 1 and role_type = 2) role
inner join
(select housedel_code, resblock_id from ods.ods_house_sh_housedel_basic_da where pt='${-1d_pt}' and del_status in (1,100,1000)) dele
on role.housedel_code = dele.housedel_code and role.org_code != ''
group by role.org_code, dele.resblock_id) fang

on myth.org_code = fang.org_code and myth.resblock_id = fang.resblock_id
where myth.housedel_num != fang.housedel_num
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章