[點晴永久免費OA][轉(zhuǎn)帖]讓SQL起飛(優(yōu)化)
最近博主看完了《SQL進階教程》這本書,看完后給博主打開了SQL世界的新大門,對于 SQL 的理解不在局限于以前的常規(guī)用法。借用其他讀者的評論,
本文給大家總結(jié)如何讓SQL起飛(優(yōu)化) 一、SQL寫法優(yōu)化在SQL中,很多時候不同的SQL代碼能夠得出相同結(jié)果。從理論上來說,我們認為得到相同結(jié)果的不同SQL之間應(yīng)該有相同的性能,但遺憾的是,查詢優(yōu)化器生成的執(zhí)行計劃很大程度上受到SQL代碼影響,有快有慢。因此如果想優(yōu)化查詢性能,我們必須知道如何寫出更快的SQL,才能使優(yōu)化器的執(zhí)行效率更高。 1.1 子查詢用EXISTS代替IN當IN的參數(shù)是子查詢時,數(shù)據(jù)庫首先會執(zhí)行子查詢,然后將結(jié)果存儲在一張臨時的工作表里(內(nèi)聯(lián)視圖),然后掃描整個視圖。很多情況下這種做法都非常耗費資源。使用EXISTS的話,數(shù)據(jù)庫不會生成臨時的工作表。但是從代碼的可讀性上來看,IN要比EXISTS好。使用IN時的代碼看起來更加一目了然,易于理解。因此,如果確信使用IN也能快速獲取結(jié)果,就沒有必要非得改成EXISTS了。 這里用Class_A表和Class_B舉例, 我們試著從Class_A表中查出同時存在于Class_B表中的員工。下面兩條SQL語句返回的結(jié)果是一樣的,但是使用EXISTS的SQL語句更快一些。 --慢 select * from Class_A where id IN (select id from Class_B); --快 select * from Class_A A where EXISTS (select * from Class_B B where A.id = B.id); 使用EXISTS時更快的原因有以下兩個。
實際上,大部分情況在子查詢數(shù)量較小的場景下EXISTS和IN的查詢性能不相上下,由EXISTS查詢更快第二點可知,子查詢數(shù)量較大時使用EXISTS才會有明顯優(yōu)勢。 1.2 避免排序并添加索引在SQL語言中,除了ORDER BY子句會進行顯示排序外,還有很多操作默認也會在暗中進行排序,如果排序字段沒有添加索引,會導致查詢性能很慢。SQL中會進行排序的代表性的運算有下面這些。
如上列出的六種運算(除了集合運算符),它們后面跟隨或者指定的字段都可以添加索引,這樣可以加快排序。
1.3 用EXISTS代替DISTINCT為了排除重復數(shù)據(jù),我們可能會使用DISTINCT關(guān)鍵字。如1.2中所說,默認情況下,它也會進行暗中排序。如果需要對兩張表的連接結(jié)果進行去重,可以考慮使用EXISTS代替DISTINCT,以避免排序。這里用Items表和SalesHistory表舉例: 我們思考一下如何從上面的商品表Items中找出同時存在于銷售記錄表SalesHistory中的商品。簡而言之,就是找出有銷售記錄的商品。 在一(Items)對多(SalesHistory)的場景下,我們需要對item_no去重,使用DISTINCT去重,因此SQL如下: select DISTINCT I.item_no from Items I INNER JOIN SalesHistory SH ON I. item_no = SH. item_no; item_no ------- 10 20 30 使用EXISTS代替DISTINCT去重,SQL如下: select item_no from Items I where EXISTS (select * from SalesHistory SH where I.item_no = SH.item_no); item_no ------- 10 20 30 這條語句在執(zhí)行過程中不會進行排序。而且使用EXISTS和使用連接一樣高效。 1.4 集合運算ALL可選項SQL中有union、INTERSECT、EXCEPT三個集合運算符。在默認的使用方式下,這些運算符會為了排除掉重復數(shù)據(jù)而進行排序。
如果不在乎結(jié)果中是否有重復數(shù)據(jù),或者事先知道不會有重復數(shù)據(jù),請使用union ALL代替union。這樣就不會進行排序了。 1.5 where條件不要寫在HAVING字句例如,這里繼續(xù)用SalesHistory表舉例,下面兩條SQL語句返回的結(jié)果是一樣的: --聚合后使用HAVING子句過濾 select sale_date, SUM(quantity) from SalesHistory GROUP BY sale_date HAVING sale_date = '2007-10-01'; --聚合前使用where子句過濾 select sale_date, SUM(quantity) from SalesHistory where sale_date = '2007-10-01' GROUP BY sale_date; 但是從性能上來看,第二條語句寫法效率更高。原因有兩個:
二、真的用到索引了嗎2.1 隱式的類型轉(zhuǎn)換如下,col_1字段是char類型: select * from SomeTable where col_1 = 10; -- 走了索引 select * from SomeTable where col_1 ='10'; -- 沒走索引 select * from SomeTable where col_1 = CAST(10, AS CHAR(2)); -- 走了索引 當查詢條件左邊和右邊類型不一致時會導致索引失效。 2.2 在索引字段上進行運算如下: select * from SomeTable where col_1 * 1.1 > 100; 在索引字段col_1上進行運算會導致索引不生效,把運算的表達式放到查詢條件的右側(cè),就能用到索引了,像下面這樣寫就OK了。 where col_1 > 100 / 1.1 如果無法避免在左側(cè)進行運算,那么使用函數(shù)索引也是一種辦法,但是不太推薦隨意這么做。使用索引時,條件表達式的左側(cè)應(yīng)該是原始字段請牢記,這一點是在優(yōu)化索引時首要關(guān)注的地方。 2.3 使用否定形式下面這幾種否定形式不能用到索引。
這個是跟具體數(shù)據(jù)庫的優(yōu)化器有關(guān),如果優(yōu)化器覺得即使走了索引,還是需要掃描很多很多行的哈,他可以選擇直接不走索引。平時我們用!=、<>、not in的時候,要注意一下。 2.4 使用OR查詢前后沒有同時使用索引例如下表: create TABLE test_tb ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(55) NOT NULL PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 使用OR條件進行查詢 select * from test_tb where id = 1 OR name = 'tom' 這個SQL的執(zhí)行條件下,很明顯id字段查詢會走索引,但是對于OR后面name字段的查詢是需要進行全表掃描的。在這個場景下,優(yōu)化器直接進行一遍全表掃描就完事了。 2.5 使用聯(lián)合索引時,列的順序錯誤使用聯(lián)合索引需要滿足最左匹配原則,即最左優(yōu)先。如果你建立一個(col_1, col_2, col_3)的聯(lián)合索引,相當于建立了 (col_1)、(col_1,col_2)、(col_1,col_2,col_3) 三個索引。如下例子: -- 走了索引 select * from SomeTable where col_1 = 10 AND col_2 = 100 AND col_3 = 500; -- 走了索引 select * from SomeTable where col_1 = 10 AND col_2 = 100 ; -- 沒走索引 select * from SomeTable where col_1 = 10 AND col_3 = 500 ; -- 沒走索引 select * from SomeTable where col_2 = 100 AND col_3 = 500 ; -- 沒走索引 select * from SomeTable where col_2 = 100 AND col_1 = 10 ; 聯(lián)合索引中的第一列(col_1)必須寫在查詢條件的開頭,而且索引中列的順序不能顛倒。 2.6 使用LIKE查詢并不是用了like通配符,索引一定會失效,而是like查詢是以%開頭,才會導致索引失效。 -- 沒走索引 select * from SomeTable where col_1 LIKE'%a'; -- 沒走索引 select * from SomeTable where col_1 LIKE'%a%'; -- 走了索引 select * from SomeTable where col_1 LIKE'a%'; 2.7 連接字段字符集編碼不一致如果兩張表進行連接,關(guān)聯(lián)字段編碼不一致會導致關(guān)聯(lián)字段上的索引失效,這是博主在線上經(jīng)歷一次SQL慢查詢后的得到的結(jié)果,舉例如下,有如下兩表,它們的name字段都建有索引,但是編碼不一致,user表的name字段編碼是utf8mb4,user_job表的name字段編碼是utf8, create TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL, `age` int NOT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; create TABLE `user_job` ( `id` int NOT NULL, `userId` int NOT NULL, `job` varchar(255) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 進行SQL查詢?nèi)缦拢?/p> EXPLAIN select * from `user` u join user_job j on u.name = j.name 由結(jié)果可知,user表的查詢沒有走索引。想要user表也走索引,那就需要把user表name字段的編碼改成utf8即可。 三、減少中間表在SQL中,子查詢的結(jié)果會被看成一張新表,這張新表與原始表一樣,可以通過代碼進行操作。這種高度的相似性使得SQL編程具有非常強的靈活性,但是如果不加限制地大量使用中間表,會導致查詢性能下降。 頻繁使用中間表會帶來兩個問題,一是展開數(shù)據(jù)需要耗費內(nèi)存資源,二是原始表中的索引不容易使用到(特別是聚合時)。因此,盡量減少中間表的使用也是提升性能的一個重要方法。 3.1 使用HAVING子句對聚合結(jié)果指定篩選條件時,使用HAVING子句是基本原則。不習慣使用HAVING子句的人可能會傾向于像下面這樣先生成一張中間表,然后在where子句中指定篩選條件。例如下面: select * from ( select sale_date, MAX(quantity) max_qty from SalesHistory GROUP BY sale_date ) tmp where max_qty >= 10 然而,對聚合結(jié)果指定篩選條件時不需要專門生成中間表,像下面這樣使用HAVING子句就可以。 select sale_date, MAX(quantity) from SalesHistory GROUP BY sale_date HAVING MAX(quantity) >= 10; HAVING子句和聚合操作是同時執(zhí)行的,所以比起生成中間表后再執(zhí)行的where子句,效率會更高一些,而且代碼看起來也更簡潔。 3.2 對多個字段使用IN當我們需要對多個字段使用IN條件查詢時,可以通過 || 操作將字段連接在一起變成一個字符串處理。 select * from Addresses1 A1 where id || state || city IN (select id || state|| city from Addresses2 A2); 這樣一來,子查詢不用考慮關(guān)聯(lián)性,而且只執(zhí)行一次就可以。 3.3 先進行連接再進行聚合連接和聚合同時使用時,先進行連接操作可以避免產(chǎn)生中間表。原因是,從集合運算的角度來看,連接做的是“乘法運算”。連接表雙方是一對一、一對多的關(guān)系時,連接運算后數(shù)據(jù)的行數(shù)不會增加。而且,因為在很多設(shè)計中多對多的關(guān)系都可以分解成兩個一對多的關(guān)系,因此這個技巧在大部分情況下都可以使用。 到此本文講解完畢,感謝大家閱讀,感興趣的朋友可以點贊加關(guān)注,你的支持將是我更新動力😘。 https://juejin.cn/post/7221735480576245819 該文章在 2023/4/19 16:18:45 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |