自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

MySQL 8.0不講武德,給我挖坑!

原創(chuàng)
數(shù)據(jù)庫 MySQL
你在使用 MySQL 的 Group by 分組時,是否發(fā)現(xiàn)分組后的數(shù)據(jù)都是有序的?

【51CTO.com原創(chuàng)稿件】你在使用 MySQL 的 Group by 分組時,是否發(fā)現(xiàn)分組后的數(shù)據(jù)都是有序的?

[[378654]] 

圖片來自 Pexels

其實(shí),在 MySQL 8.0 ,優(yōu)化器在分組查詢時都會進(jìn)行隱式排序。那既然隱式排序?yàn)槭裁催€要保留 Order by?隱式排序的目的又是什么呢?讓我們一起來看看。

背景小故事

年前我們換了領(lǐng)導(dǎo),俗話說,新官上任總愛干傻事兒...

這不,領(lǐng)導(dǎo)要擁抱新事物,要求我們更新項(xiàng)目 MySQL 版本,從 MySQL 5.7 更新到 MySQL 8.0。不知是 MySQL 5.7 不香了,還是領(lǐng)導(dǎo)你眼光高了?

我把這個任務(wù)交給同事小王,小王不以為然,說換就換。遷完庫,在代碼基本不改的情況下自信上線。

上線后卻發(fā)現(xiàn)原本一些有序的列表變無序了,最后臨時回退了版本。

[[378655]] 

核對代碼時我們發(fā)現(xiàn),老版本 Select 語句中只是用到了 Group by 分組,也沒有用到 Order by 排序,有點(diǎn)蒙,為啥沒用 Order by 卻排了序?

查資料后得知,在 MySQL 8.0 版本前是存在 Group by 隱式排序的!

就是說在我們使用分組(Group by)時,如:

  1. select * from T group by appName; 

會默認(rèn)按照 appName 正序排序,相當(dāng)于:

  1. select * from T group by appName order by appName; 

倒排同理:

  1. select * from T group by appName desc

可見,MySQL 在 8.0 版本前的分組查詢中,偷偷加上了排序操作。

納尼?MySQL 還有這種操作?快找一下官方文檔對 Group by 隱式排序的介紹:

官方文檔

官方文檔 MySQL 5.7 Reference Manual 中的“2.1.14 ORDER BY Optimization”章節(jié)有如下介紹:

GROUP BY implicitly sorts by default (that is, in the absence of ASC or DESC designators for GROUP BY columns). However, relying on implicit GROUP BY sorting (that is, sorting in the absence of ASC or DESC designators) or explicit sorting for GROUP BY (that is, by using explicit ASC or DESC designators for GROUP BY columns) is deprecated. To produce a given sort order, provide an ORDER BY clause.

Google 翻譯:默認(rèn)情況下 GROUP BY 隱式排序(即,缺少 GROUP BY 列的 ASC 或 DESC 指示符)。

但是,不推薦依賴于隱式 GROUP BY 排序(即,在沒有 ASC 或 DESC 指示符的情況下排序)或 GROUP BY 的顯式排序(即,通過對 GROUP BY 列使用顯式 ASC 或 DESC 指示符)。

要生成給定的排序 ORDER,請?zhí)峁?ORDER BY 子句。

從 MySQL 8.0 開始,GROUP BY 字段不再支持隱式排序。官方文檔 MySQL 8.0 Reference Manual中“8.2.1.16 ORDER BY Optimization”章節(jié)有如下介紹:

Previously (MySQL 5.7 and lower), GROUP BY sorted implicitly under certain conditions. In MySQL 8.0, that no longer occurs, so specifying ORDER BY NULL at the end to suppress implicit sorting (as was done previously) is no longer necessary. However, query results may differ from previous MySQL versions. To produce a given sort order, provide an ORDER BY clause.

Google 翻譯:以前(MySQL 5.7 及更低版本),GROUP BY 在某些條件下隱式排序。

在 MySQL 8.0 中,不再發(fā)生這種情況,因此不再需要在末尾指定 ORDER BY NULL 來抑制隱式排序(如前所述)。

但是,查詢結(jié)果可能與以前的 MySQL 版本不同。要產(chǎn)生給定的排序順序,請?zhí)峁?ORDER BY 子句。

陳哈哈:“哦,這么看來開發(fā)老版本的同事是沒用 Order by,直接用了隱式排序。年輕人,不講武德啊!!”

小王(小聲):“哈哥,這模塊之前好像是你負(fù)責(zé)的。”

陳哈哈(老臉一紅):???

陳哈哈:“咳咳,這 MySQL 8.0 團(tuán)隊不講武德,給我挖坑!”

[[378656]] 

好了,接下來我們用測試數(shù)據(jù)演示一下。

數(shù)據(jù)測試

下面是表 T 測試數(shù)據(jù),無序:

  1. mysql> SELECT pid,appName from T;     
  2. +--------+-------------------------+ 
  3. | pid    | appName                 | 
  4. +--------+-------------------------+ 
  5. |      1 |  Dock Sound Redirector  | 
  6. |      2 |  Blues Music station    | 
  7. |      3 |  usb tether TRIAL       | 
  8. |      4 |  Il vero test del QI    | 
  9. |      5 |  FlightTime Calculator  | 
  10. |      6 |  ZX Spectrum Emulator   | 
  11. |      7 |  The City Dress Up      | 
  12. +--------+-------------------------+ 
  13. rows in set (0.00 sec) 

實(shí)驗(yàn) 1:(MySQL 版本:5.7.24)

  1. -- 隱式排序 
  2. mysql> SELECT pid,appName from T group by appName;     
  3. +--------+-------------------------+ 
  4. | pid    | appName                 | 
  5. +--------+-------------------------+ 
  6. |      2 |  Blues Music station    | 
  7. |      1 |  Dock Sound Redirector  | 
  8. |      5 |  FlightTime Calculator  | 
  9. |      4 |  Il vero test del QI    | 
  10. |      7 |  The City Dress Up      | 
  11. |      3 |  usb tether TRIAL       | 
  12. |      6 |  ZX Spectrum Emulator   | 
  13. +--------+-------------------------+ 
  14. rows in set (0.00 sec) 
  15. -- 如上述隱式排序,相當(dāng)于SELECT pid,appName from T group by appName asc 或 SELECT pid,appName from T group by appName order by appName asc; 
  16. -- 顯式排序,相當(dāng)于SELECT pid,appName from T group by appName order by appName desc; 
  17. mysql> SELECT pid,appName from T group by appName desc;     
  18. +--------+-------------------------+ 
  19. | pid    | appName                 | 
  20. +--------+-------------------------+ 
  21. |      6 |  ZX Spectrum Emulator   | 
  22. |      3 |  usb tether TRIAL       | 
  23. |      7 |  The City Dress Up      | 
  24. |      4 |  Il vero test del QI    | 
  25. |      5 |  FlightTime Calculator  | 
  26. |      1 |  Dock Sound Redirector  | 
  27. |      2 |  Blues Music station    | 
  28. +--------+-------------------------+ 
  29. rows in set (0.00 sec) 

實(shí)驗(yàn) 2:(MySQL 版本:8.0.16)

  1. mysql> SELECT pid,appName from T group by appName;     
  2. +--------+-------------------------+ 
  3. | pid    | appName                 | 
  4. +--------+-------------------------+ 
  5. |      1 |  Dock Sound Redirector  | 
  6. |      2 |  Blues Music station    | 
  7. |      3 |  usb tether TRIAL       | 
  8. |      4 |  Il vero test del QI    | 
  9. |      5 |  FlightTime Calculator  | 
  10. |      6 |  ZX Spectrum Emulator   | 
  11. |      7 |  The City Dress Up      | 
  12. +--------+-------------------------+ 
  13. rows in set (0.00 sec) 
  14. mysql> SELECT pid,appName from T group by appName DESC
  15. ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DESC' at line 1 

如上所示,在 MySQL 8.0 中,GROUP BY 隱式排序不支持了,上面測試?yán)邮菬o序的。GROUP BY 顯示排序則直接報錯。

所以如果有數(shù)據(jù)庫從 MySQL 5.7 或之前的版本,遷移升級到 MySQL 8 的話,就需要特別留意這個問題了。

隱式排序:起源(一個優(yōu)美的 Bug)

最初為什么要用隱式排序呢?我們知道,要對一組數(shù)據(jù)進(jìn)行分組,MySQL 優(yōu)化器會選擇不同的方法。

其中最有效的一種是分組之前對數(shù)據(jù)排序,降低數(shù)據(jù)復(fù)雜度,使得連續(xù)分組變得很容易。

另外,如果可以 Group by 一個索引字段來用于獲取排序的數(shù)據(jù),那么使用它的成本就非常低了(因?yàn)?BTree 索引是天然有序的)。

而在實(shí)際操作中,Group by 用到索引的頻率很高。這么看,這確實(shí)是個很棒的主意!也可以說是留了一個優(yōu)美的 Bug。

如下查詢語句,用到了 appName_idx 索引,因此 Group by 查詢不需要排序,直接分組,高效。

  1. -- 有索引:appName_idx 
  2. mysql> EXPLAIN SELECT appName from 0122_csj_demo GROUP BY appName \G 
  3. *************************** 1. row *************************** 
  4.            id: 1 
  5.   select_type: SIMPLE 
  6.         table: 0122_csj_demo 
  7.    partitions: NULL 
  8.          type: index 
  9. possible_keys: appName_idx 
  10.           key: appName_idx 
  11.       key_len: 515 
  12.           ref: NULL 
  13.          rows: 28 
  14.      filtered: 100.00 
  15.         Extra: Using index 
  16. 1 row in set, 1 warning (0.00 sec) 

如果沒有索引,MySQL 優(yōu)化器仍然可以決定在分組之前用外部臨時表進(jìn)行 filesort 排序,從效率上講,和無序分組差不多。

當(dāng)用戶指定 Order by 時,是 MySQL 最希望看到的,這樣就不會讓排序工作白費(fèi),這也是讓 MySQL 團(tuán)隊始終默認(rèn)隱式排序存在的原因之一。

  1. mysql> EXPLAIN SELECT appName from 0122_csj_demo GROUP BY appName \G 
  2. *************************** 1. row *************************** 
  3.            id: 1 
  4.   select_type: SIMPLE 
  5.         table: 0122_csj_demo 
  6.    partitions: NULL 
  7.          type: ALL 
  8. possible_keys: NULL 
  9.           keyNULL 
  10.       key_len: NULL 
  11.           ref: NULL 
  12.          rows: 28 
  13.      filtered: 100.00 
  14.         Extra: Using temporary; Using filesort 
  15. 1 row in set, 1 warning (0.00 sec) 

另外,用戶可以顯式指定 ORDER BY NULL 就能讓 MySQL 知道 GROUP BY 不需要排序。

因此需要一個非標(biāo)準(zhǔn)(ORDER BY NULL)語法來抵消另一個非標(biāo)準(zhǔn)擴(kuò)展(GROUP BY 排序)的影響。

  1. mysql> EXPLAIN SELECT appName from 0122_csj_demo GROUP BY appName ORDER BY null \G 
  2. *************************** 1. row *************************** 
  3.            id: 1 
  4.   select_type: SIMPLE 
  5.         table: 0122_csj_demo 
  6.    partitions: NULL 
  7.          type: ALL 
  8. possible_keys: NULL 
  9.           keyNULL 
  10.       key_len: NULL 
  11.           ref: NULL 
  12.          rows: 28 
  13.      filtered: 100.00 
  14.         Extra: Using temporary 
  15. 1 row in set, 1 warning (0.00 sec) 

隱式排序:宿命

為了解決這個優(yōu)美的 Bug,MySQL 團(tuán)隊在 8.0 版本引入了倒排索引。正負(fù)向索引排序的優(yōu)化思路,給隱式排序體面的落下帷幕。

自此 Group by 隱式排序功能被刪除,分組排序必須用 Order by 來進(jìn)行,分組的算法依然可以基于正負(fù)向索引延續(xù)之前分組的高效性。

好了,本文到此基本結(jié)束,隱式排序算是 MySQL 角落里較冷門的知識點(diǎn),對我來說卻是一位結(jié)識四年的舊友了。

北漂四年,時光匆匆,從初識 MySQL 的步履維艱,到深入理解各知識點(diǎn)的實(shí)現(xiàn)思路,也算順道吃了杯隱排的踐行酒。

莫泊桑說:"生活可能不像你想象的那么好,但是,也不會你想象的那么糟"。

人的脆弱和堅強(qiáng)都超乎了自己的想,有時候可能脆弱的一句話,就淚流滿面。

[[378657]] 

有時候你會發(fā)現(xiàn),自己咬著牙走過很長的一段路。在外漂泊打工人不易,為了家人父母過上好日子,加油!

作者:陳哈哈

簡介:MySQL 社區(qū)的非著名貢獻(xiàn)者,一個愛笑的程序員,善于白嫖知識;陪伴 MySQL 五年,致力于高性能 SQL、事務(wù)鎖優(yōu)化方面的研究;長路漫漫,希望通過自己的分享讓大家少踩一些坑。

編輯:陶家龍

征稿:有投稿、尋求報道意向技術(shù)人請聯(lián)絡(luò)小編微信:gordonlonglong

【51CTO原創(chuàng)稿件,合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

 

責(zé)任編輯:武曉燕 來源: 51CTO技術(shù)棧
相關(guān)推薦

2020-12-07 08:04:39

CTO中年公司

2021-05-26 05:40:32

加密勒索軟件攻擊

2020-12-25 11:37:32

DDoS攻擊信用卡黑客

2021-07-06 21:37:05

索引SQL數(shù)據(jù)

2022-01-13 06:49:23

開源項(xiàng)目刪庫

2021-09-14 11:57:01

雙重勒索勒索軟件黑客攻擊

2020-11-24 08:02:26

API接口重構(gòu)

2021-02-28 07:52:24

蠕蟲數(shù)據(jù)金絲雀

2021-01-29 14:35:41

代碼開發(fā)服務(wù)器

2020-12-03 18:18:46

微信表情下回

2021-05-31 09:03:12

算法數(shù)據(jù)技術(shù)

2025-04-07 09:10:15

2021-04-26 15:04:32

Linux 系統(tǒng) 數(shù)據(jù)

2020-11-17 09:01:09

MySQLDelete數(shù)據(jù)

2020-04-23 14:09:13

URI挖坑前端

2024-01-17 14:00:00

數(shù)據(jù)模型

2021-10-19 10:26:31

MySQL.MySQLJSON

2018-05-03 10:33:14

數(shù)據(jù)庫MySQL 8.0角色管理

2022-09-20 10:44:06

MySQL 8.0數(shù)據(jù)庫DDL

2013-07-09 09:11:50

程序員
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號