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

從 LeetCode 的題目再看 MySQL Explain

數(shù)據(jù)庫 MySQL
今天阿粉主要是想通過 LeetCode 上面的一個(gè)題目來再帶大家看看 MySQL 的變量使用以及通過 Explain 的解析看看SQL 的執(zhí)行過程。

[[376540]]

本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」,作者鴨血粉絲 。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。  

今天阿粉主要是想通過 LeetCode 上面的一個(gè)題目來再帶大家看看 MySQL 的變量使用以及通過 Explain 的解析看看SQL 的執(zhí)行過程。雖然平時(shí)在工作中對(duì)于 MySQL 使用的很多,但是相對(duì)于 MySQL 的變量使用相對(duì)還是較少的,所以阿粉在剛看到的時(shí)候還是有點(diǎn)懵的,不過我相信大家肯定不會(huì)像阿粉一樣,畢竟能關(guān)注我們公眾號(hào)的讀者都是優(yōu)秀的。

題目

題目描述:編寫一個(gè) SQL 查詢,查找所有至少連續(xù)出現(xiàn)三次的數(shù)字。并且給了一個(gè)示例,阿粉按照題目給的示例在本地創(chuàng)建了 Logs 表和插入相應(yīng)的數(shù)據(jù),如下:

我們可以看到在給定上面的 Logs 表中, 1 是唯一連續(xù)出現(xiàn)至少三次的數(shù)字,所以最后輸出的結(jié)果是 1。

原始題目:LeetCode 180

剛看到題目的時(shí)候,阿粉一瞬間還是沒反應(yīng)過來,不知道該如何著手進(jìn)行,思索了一下考慮是否可以用自連接來實(shí)現(xiàn)呢?然后根據(jù)題目的意思就寫出了如下的 SQL。

  1. SELECT DISTINCT 
  2.  l1.num  
  3. FROM 
  4.  `Logs` l1, 
  5.  `Logs` l2, 
  6.  `Logs` l3  
  7. WHERE 
  8.  l1.num = l2.num  
  9.  AND l2.num = l3.num  
  10.  AND l1.id = l2.id - 1  
  11.  AND l2.id = l3.id - 1 

寫完過后阿粉第一次提交,提示下面錯(cuò)誤,可以看到是最后沒有將返回重命名,調(diào)整了一下 SQL,就l1.num 改成l1.num as ConsecutiveNums 再次提交,得到的第二張通過的圖。

看開始看到通過,阿粉還在想這道題也沒什么啊,還是 so easy 的嘛。但是突然阿粉轉(zhuǎn)念一想,這個(gè)題目說的是連續(xù)出現(xiàn),并沒有說 ID 是連續(xù)的啊,如果 ID 不連續(xù)的話,這種就不對(duì)了,還有就是如果需要連續(xù) 4 次出現(xiàn)的,5 次出現(xiàn)的數(shù)字呢?總不能一直自連接下去吧。如果寫成這樣那整個(gè) SQL 就太不靈活了。

隨后阿粉就看了一下官方解答以及相關(guān)評(píng)論,果不其然雖然官方給出的解答跟阿粉的一致,但是下面的評(píng)論卻有很多小伙伴都在說這個(gè) ID 不連續(xù)的問題。

既然反饋這種做法有問題,那自然就會(huì)有好事之者會(huì)想到解決辦法,果然評(píng)論區(qū)的一個(gè)大佬給出了下面的這種解法

剛看到這個(gè)解法的時(shí)候,阿粉一下子沒有看懂,把這個(gè)代碼進(jìn)行了提交,果然也是正常的通過了。而且這種解法不會(huì)被出現(xiàn)幾次的條件給限制。抱著學(xué)習(xí)的心態(tài),阿粉準(zhǔn)備研究一下這條 SQL 里面的內(nèi)容。

SQL 拆解

首先這條 SQL 里面有這么幾個(gè)地方讓阿粉迷惑,第一個(gè)是@ 符號(hào),然后是:= 然后還有個(gè) case when then 語法,平日里在 CRUD 的時(shí)候沒遇到過這種寫法,不過不知道沒關(guān)系,Google 一下就好了。網(wǎng)上查了下,@prev 表示的是聲明變量,:=操作是 MySQL 的賦值操作,case when then when 后面接的是判斷條件,條件成立則會(huì)返回then 后面的結(jié)果,需要注意的是 case 只會(huì)返回第一個(gè)符合條件的結(jié)果,剩下將會(huì)被忽略。

簡單的了解了上面幾個(gè)知識(shí)點(diǎn)過后,我們就可以對(duì)下面這條 SQL 進(jìn)行拆解了。

  1. select distinct Num as ConsecutiveNums 
  2. from ( 
  3.   select Num,  
  4.     case  
  5.       when @currnet = Num then @count := @count + 1 
  6.       when (@currnet := Num) is not null then @count := 1 
  7.     end as CNT 
  8.   from Logs, (select @currnet := null,@count := 0) as t 
  9. as temp 
  10. where temp.CNT >= 3 
  1. 最外層的 select distinct Num as ConsecutiveNums from () as temp where temp.CNT >= 3 ; 我們可以看到中間的小括號(hào)里面被派生成了一個(gè)臨時(shí)表,表名叫做 temp,并且 temp 表中有兩個(gè)字段分別是Num,CNT。其實(shí)Num 則是表Logs 里面的數(shù)字,CNT 則是連續(xù)出現(xiàn)的累積次數(shù),最后的where temp.CNT >= 3 則是在根據(jù)要求連續(xù)出現(xiàn)的次數(shù)進(jìn)行查詢。
  2. 派生語句SELECT Num,CASE WHEN @currnet=Num THEN @count:=@count+1 WHEN (@currnet:=Num) IS NOT NULL THEN @count:=1 END AS CNT FROM LOGS,(SELECT @currnet:=NULL,@count:=NULL) AS t 包含兩個(gè)部分,一個(gè)是Select 中的case when then 另一個(gè)是from 中的 (select @currnet:= null,@count := null) as t 其中select @currnet:= null,@count := null 也是一個(gè)派生表,這里通過聲明兩個(gè)變量@currnet, @count 并賦值為null 。
  3. 中間派生的表 temp 的內(nèi)容如下,通過生成記錄每個(gè)數(shù)字出現(xiàn)的次數(shù)的臨時(shí)表來查詢數(shù)據(jù)。

下面我們通過explain 命令看下整個(gè) SQL 的執(zhí)行過程,:

  • 從select_type中我們可以看到總共派生了兩個(gè)表,跟我們上面分析的一致;
  • ID 為 3 的派生表的內(nèi)容是select @current := null,@count := 0 定義兩個(gè)變量并賦值,并且 id 越大越先執(zhí)行;
  • case 語句中第一個(gè)when 中判斷當(dāng)前掃描到的 num 值與定義的變量是否一致,如果一致則 count 加一,不一致則進(jìn)行下一個(gè)when 條件判斷,并將count 賦值為 1 返回;
  • 經(jīng)過全表掃描過后,就得到了上面的中間表 temp 的內(nèi)容;

不得不說,上面的方案是很完美的,不存在 ID 是否連續(xù)的問題,也不會(huì)多層自連接,而且也可以根據(jù)要求找出連續(xù)出現(xiàn)的次數(shù),相對(duì)靈活。剛開始看到這個(gè) SQL 的時(shí)候,阿粉并不清楚整個(gè)執(zhí)行的過程,然后通過 explain 才漸漸明白整個(gè)執(zhí)行過程, 而且對(duì)于在 SQL 中使用變量也有了一定的了解。

 

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

2017-07-27 20:00:47

MySQLEXPLAIN命令

2010-10-12 13:55:41

MySQL EXPLA

2014-02-04 07:59:27

2011-08-18 11:31:06

MySQL性能分析explain

2025-02-18 12:50:00

MySQL命令數(shù)據(jù)庫

2017-04-07 14:30:26

2025-02-19 07:49:36

2010-05-21 16:55:47

MySQL EXPLA

2023-09-21 10:55:51

MysqlSQL語句

2009-12-10 16:12:07

EXPLAIN

2024-12-11 13:14:27

2011-04-19 12:32:41

2022-02-15 07:36:21

SQLEXPLAIN數(shù)據(jù)庫

2021-03-01 08:20:06

AndroidFileProvideContentProv

2010-05-19 10:37:06

MySQL expla

2024-09-12 15:16:14

2023-09-05 07:29:01

2020-10-19 19:45:58

MySQL數(shù)據(jù)庫優(yōu)化

2019-09-17 15:13:05

MySQLEXPLAIN數(shù)據(jù)庫

2019-07-16 11:06:09

TCP四次揮手半關(guān)閉
點(diǎn)贊
收藏

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