『壹』 sql語句對數據分析重要嗎
樓主好，SQL對數據分析相當重要，我當前就入行了數據分析行業。其實說白了所謂數據分析，首先要有數據，而你寫的SQL就成了數據。其實換到數據分析行業中講，你要分析首先就要有數據倉庫和數據集，而如何能得到這些數據，就全是SQL寫出來的，然後通過工具載入到固定的資料庫中，就得到了數據倉庫。就算是你在做分析類型的報表，也全部都是SQL語句寫出來，得到數據，載入到報表中的。數據挖掘也是要獲取到數據的，當然也是SQL。所以想要做數據分析，SQL是必須過關的。
『貳』 數據分析人必掌握的資料庫語言-SQL指南第六期
本篇文章繼續圍繞SQL的語法重點為大家介紹 連接 和 高級連接 的使用，以及 使用連接的注意事項 。
SQL最強大的功能之一就是能在數據查詢的執行中 連接（join）表 。連接是利用SQL的SELECT語句能執行的最重要的操作，很好地理解連接及其語法是學習SQL的極為重要的一點。在能夠有效地使用連接前，我們必須了解 關系表 以及 關系資料庫 設計的一些基礎知識。下面的介紹並不能涵蓋這一主題的所有內容，但作為入門已經夠了。
連接
理解關系表，最好是來看個例子。
有一個包含產品目錄的資料庫表，其中每類物品佔一行。
對於每一種物品，要存儲的信息包括產品描述、價格，以及生產該產品的供應商。
現在有同一供應商生產的多種物品，那麼在何處存儲供應商名、地址、聯系方法等供應商信息呢？將這些數據與產品信息分開存儲的理由是：
① 同一供應商生產的每個產品，其供應商信息都是相同的，對每個產品重復此信息既浪費時間又浪費存儲空間；
② 如果供應商信息發生變化，例如供應商遷址或電話號碼變動，只需修改一次即可；
③ 如果有重復數據（即每種產品都存儲供應商信息），則很難保證每次輸入該數據的方式都相同。不一致的數據在報表中就很難利用。
關鍵是， 相同的數據出現多次不是一件好事 ，這是關系資料庫設計的基礎。
關系表的設計就是要 把信息分解成多個表 ， 一類數據一個表 。各表通過某些共同的值互相關聯（所以才叫關系資料庫）。在這個例子中可建立兩個表：一個存儲供應商信息，另一個存儲產品信息。Vendors表包含所有供應商信息，每個供應商佔一行，具有唯一的標識。此標識稱為 主鍵 （primary key），可以是供應商ID或任何其他唯一值。Procts表只存儲產品信息，除了存儲供應商ID（Vendors表的主鍵）外，它不存儲其他有關供應商的信息。Vendors表的主鍵將Vendors表與Procts表關聯，利用供應商ID能從Vendors表中找出相應供應商的詳細信息。
這樣做的 好處 是：
① 供應商信息不重復，不會浪費時間和空間；
② 如果供應商信息變動，可以只更新Vendors表中的單個記錄，相關表中的數據不用改動；
③ 由於數據不重復，使得處理數據和生成報表更簡單。
總之，關系數據可以有效地存儲，方便地處理。因此，關系資料庫的可伸縮性遠比非關系資料庫要好。
為什麼使用連接
連接將數據分解為多個表實現 更有效 地存儲、 更方便 地處理，且 可伸縮性更好 。
可伸縮性：能夠適應不斷增加的工作量而不失敗。
連接作為一種機制，能在一條SELECT語句中用來關聯表。使用特定的語法，可連接多個表返回一組輸出。
創建連接
分析 ：上述SELECT語句中與之前的語句相同，都是指定檢索的列， 區別 在於該語句指定的兩列（prod_name,prod_price）在一個表中，而第一列（vend_name）在另一個表中。
FROM子句也有所區別。該FROM子句列出了兩個表：Vendors,Procts。這兩個表由SELECT語句的WHERE子句連接。WHERE子句指示DBMS將Vendors表中的vend_id與Procts表中的vend_id匹配起來。
這里使用了 完全限定列名 將Vendors.vend_id和Procts.vend_id兩列匹配。最終輸出了兩個不同表中的數據。
高級連接部分將介紹 如何使用表別名，另外的一些連接 ，以及 如何對被連接的表使用聚集函數 。
使用表別名
之前的文章已經給大家介紹了如何使用別名引用被檢索的表列。
SQL還可以 給表名起別名 ，目的是：
① 縮短SQL語句。
② 允許在一條SELECT語句中多次使用相同的表。
分析 ：上述語句中的FROM子句的三個表都有別名。如此 省略了許多字元 。表別名還可以用於SELECT的列表、ORDER BY子句以及其他語句部分。
需要注意的是： 表別名只在查詢執行中使用 。與列別名不同，表別名不返回到客戶端。
使用不同類型的連接
接下來將給大家介紹四種其他類型的連接： 自連接 、 自然連接 、 內連接 和 外連接 。
①自連接
分析： 這是使用了 子查詢 的方案。對內部的SELECT語句做了一個簡單的檢索，返回Jim Jones工作公司的cust_name。該數據用於外部查詢的WHERE子句中，以檢索出為該公司工作的所有雇員。
下面看看使用了 連接 的方案。
分析：上述語句需要的兩個表實際上是相同的表，所以Customers表在FROM子句中出現了兩次。但這對於Customers的引用具有歧義，因為沒有指示DBMS引用的是哪個Customers表。
於是需要使用表別名解決該問題。Customers表 第一次出現為別名c1 ， 第二次為c2 ，然後再將這些別名用作表名。如SELECT語句使用c1前綴明確給出所需列的全名。如果不這么做，DBMS將返回錯誤，因為名為cust_id、cust_name、cust_contact的列各有兩個。DBMS不知需要哪一列，即使它們都是同一列。
WHERE首先連接兩個表，再按第二個表中的cust_contact過濾數據，返回所需的數據。
②自然連接
內連接 返回所有的數據，其中 相同的列可多次出現 。而 自然連接排除多次出現 ，使每一列只返回一次。
一般通過對一個表使用通配符（SELECT *），而對其他的列使用明確的子集來實現自然連接。
分析： 上述語句中，通配符只對第一個表使用，而所有其他列都明確列出來，所以沒有出現重復的列被檢索出來。
③內連接
目前為止使用的連接稱為等值連接，是基於兩個表之間的相等測試。該連接也稱為內連接。
對該種連接還可以使用不同的語法，明確指定連接的類型。
分析 ：該語句中的SELECT與之前的區別在於FROM 子句。此處兩個表之間的關系是以 INNER JOIN 指定的部分FROM子句，因此需要使用特定的 ON子句 而不是WHERE子句。但傳遞給ON的實際條件與WHERE相同。
④外連接
許多連接將一個表中的行與另一個表中的行相關聯，但有時候 需要包含沒有關聯的行 。例如，可能需要使用連接完成以下工作：
對每個顧客下的訂單進行計數，包括那些至今尚未下訂單的顧客；
列出所有產品以及訂購數量，包括沒有人訂購的產品；
計算平均銷售規模，包括那些至今尚未下訂單的顧客。
在上述例子中，連接包含了那些在相關表中沒有關聯行的行。這種連接稱為外連接，外連接分為 左外連接 和 右外連接 。
左外連接：取左邊的表的全部，而右邊的表按照條件顯示，不符合條件的顯示NULL。
右外連接：取右邊的表的全部，而左邊的表按照條件顯示，不符合條件的顯示NULL。
下面先給出一個簡單的 內連接 ，再給出 左外連接 ，大家對比著理解。
分析 ：兩個語句都使用了 JOIN 關鍵字來指定連接類型，與內連接不同的是，左外連接包括沒有關聯行的行。因此在使用JOIN語法時，還需使用RIGHT或LEFT關鍵字來指定包括其所有行的表（RIGHT指出的是OUTER JOIN右邊的表，而LEFT指出的是OUTER JOIN左邊的表）。
上述左外連接語句使用了LEFT OUTER JOIN 從FROM子句左邊的表（Customers）中選擇所有行。
若要從右邊的表選擇所有行，即使用 右外連接 ，則語句如下：
注意 ：兩種基本的外連接形式，左外連接和右外連接。兩者的唯一差別是所關聯的表的順序。
此外，還有一種外連接，即 全外連接 。該連接檢索兩個表中的所有行並關聯可關聯的行。與左外連接或右外連接包含一個表的不關聯的行不同，全外連接包含兩個表的不關聯的行。
自連接、自然連接、內連接和外連接的區別
①自連接： 通常用於 兩張結構和數據內容完全一樣的表 ，在做數據處理時，對它們分別 重命名 來加以區分，然後再進行關聯。
②自然連接 ：特點是要求兩個關系表中進行連接的必須是 相同屬性列 （名字相同），無需添加連接條件，且 在結果中消除了重復的屬性列 。
③內連接 ：與自然連接相似，區別在於內連接 不要求兩屬性列同名 ，可以用 using或on 來指定某兩列欄位相同的連接條件。
④外連接 ：可以解決自然連接時某些屬性不同導致這些元組被舍棄的問題，起到了 保留要舍棄的結果 的作用。
使用帶聚集函數的連接
之前給大家介紹過使用 聚集函數 來匯總數據，殊不知這些函數也可以與連接一起使用。
分析： 上述語句使用了 COUNT函數 。該語句使用INNER JOIN將Customers和Orders表相互關聯。GROUP BY子句按顧客分組，因此，函數調用COUNT(Orders.order_num)對每個顧客的訂單計數，將其作為num_ord返回。
分析： 上述語句使用 左外連接 包含所有顧客，包括了那些沒有任何訂單的顧客。
WHERE子句的重要性
需記住的是，在一條SELECT語句中連接幾個表時，相應的關系是在運行中構造的，因為在資料庫表中的定義沒有指示DBMS如何對表進行連接的內容。
要連接多個表，需要將它們並列於from之後， 關鍵 是要設置WHERE子句，確保它們之間的 關聯關系 必須給出，否則，查詢結果會成為笛卡爾積。
笛卡爾積：由沒有連接條件的表關系返回的結果為笛卡兒積。
分析 ：上述語句輸出的結果便是 笛卡爾積 。返回的數據用每個供應商匹配了每個產品，包括了供應商不正確的產品（即使該供應商沒有產品）。
連接及其使用的要點
① 注意所使用的連接類型。一般我們使用內連接，但使用外連接也有效。
② 關於確切的連接語法，應該查看具體的文檔，看相應的DBMS支持何種語法（大多數DBMS使用這兩課中描述的某種語法）。
③ 保證使用正確的連接條件（不管採用哪種語法），否則會返回不正確的數據。
④ 應該總是提供連接條件，否則會得出笛卡兒積。
⑤ 在一個連接中可以包含多個表，甚至可以對每個連接採用不同的連接類型。雖然這樣做是合法的，一般也很有用，但應該在測試它們前分別測試每個連接。這會使故障排除更為簡單。
以上就是本次介紹的連接和高級連接啦~
下一期將給大家介紹 組合查詢 、 插入數據 及 更新和刪除數據。
我們下期見！
『叄』 什麼是數據分析如何學習數據分析
【導讀】無論是從薪資待遇還是未來的發展前景，數據分析師都是屈指可數的稀缺人才，那麼什麼是數據分析?如何學習數據分析呢?下面跟著小編一起來分析一下吧!
什麼是數據分析?
對於數據分析的概念，我們需要有一個深刻的理解。數據分析是指用適當的統計分析方法對收集來的大量數據進行分析，將它們加以匯總和理解並消化，以求最大化地開發數據的功能，發揮數據的作用。
如何學習數據分析?
的確，興趣能作為你學習下去的動力，但是後續不斷地學習並掌握技能才是根配拍本。小編以前特別喜歡吉他，於是就報了吉他班。彈吉他確實是一件很酷的事，但是學習過程卻非常艱辛。我的手指尖經常因為手運彈吉他生成黃黃的老繭。有時候我甚至想要放棄，但是在培薯羨老師和父母的監督下，我還是堅持了下來。
學習數據分析的過程何嘗不是如此呢?想要實現夢想，就一定要付諸汗水。以下便是小編為小白們提的幾點學習數據分析的建議~
1.瀏覽各大平台有關數據分析的論壇。
很多技術大牛在網路貼吧、知乎、B站、CSDN等平台都發布過自己的經驗貼，積少成多的知識可以幫助我們少走很多彎路，從而更快地掌握知識。
2.運用數據集開啟項目。
感興趣的小夥伴可以點擊下方鏈接康康小編推薦過的數據集~
3.掌握數據分析師的必備技能。
(1)Excel。很多人的電腦里都安裝了Excel這款軟體。在辦公時，我們經常會用Excel製作表格。除此之外，Excel還是一款數據管理工具，可以用於數據的清理、分析和可視化。
(2)SQL。SQL是一種資料庫查詢和程序設計語言，用於存取數據以及查詢、更新和管理關系資料庫系統。
(3)Tableau等可視化軟體。Tableau這一款可視化工具廣泛運用於商業領域。並且，Tableau是一款自帶教程的軟體，省去了我們去別的平台找學習視頻的時間。
以上就是小編今天給大家整理發送的關於「什麼是數據分析?如何學習數據分析?」的相關內容，希望對大家有所幫助。小編認為要想在大數據行業有所建樹，需要考取部分含金量高的數據分析師證書，這樣更有核心競爭力與競爭資本。
『肆』 用SQL做簡單數據分析（入門級）
你要的分析功能已經有智能分析的要求了
這超出了sql現有的功能 ，只用sql語句是無法直接打到這種分析的
『伍』 詳細講解如何用SQLyog來分析MySQL資料庫
我去了相關網站下載，它只有384K位元組大小。它把兩個文件（一個可執行文件.exe和一個動態鏈接庫文件.dll）安裝到C:\Program Files\SQLyog路徑下。然後運行可執行文件。 安裝後沒有必要再訪問該網站了，我訪問該網站是得到了一個消息，說它的域名沒有設置（configured）、登記、或正在建設中。我不清楚這個問題是暫時的還是一直是這樣。該軟體是免費的，並且沒有標志廣告（banner ads），所以它可能是一個特定的尚未最終定型的商業模型。最終可能還是要負費的。 資料庫、表格（table）和列樹（column tree）該程序一啟動就開始詢問我的登錄到MySOL伺服器的口令。我只需要輸入我的伺服器名字、用戶id和登錄密碼。所有其它的設置都是正確的默認值。然後（當我開始其它事務、弊磨重啟幾次、睡了一會之後），我重新運行該程序，這時只需要再次輸入我的登錄密碼。該程序沒有保存密碼的選項，你可以認為這是該程序的一個bug，也可以說是程序的保密特性。 一旦你登錄之後，界面就是很值得注意。MySOL伺服器上所有的資料庫都顯示在一個樹型控制項上。你只能訪問你在登錄時授權的那個資料庫。如果你點開代表授權給你的那個資料庫的樹型結構，你就可以看到一系列代表表格的節點。點開表格節點後，你就可以看到一系列顯示欄位名的節點和另一個代表索引的節點集合。 索引界面絕對是個好東東，這遲卜扒樣你就可以CRUD查詢索引和關鍵字了。這相對前端資料庫如Microsoft Access來說是個提高。如果考慮到MySOL剛剛開始提供對主（primary）和非相關（foreign）關鍵字關系的支持，本程序這部分的設計是很成熟的。在右下方的面板上，有四個標簽頁，即：結果（Result）、消息（Message）、對象（Object）和歷史（History）。 有什麼缺點？我試圖發現該程序的缺點，不過只發現了一個。如果你在Win32 Dependency Walker下運行程序的.exe文件，你會發現它引用了COMDLG32.dll文件，碼昌而COMDLG32.dll又輪流引用AppHelp。實事上，CommDlg調用AppHelp，而當AppHelp沒有請求函數時，CommDlg這么做根本就是浪費資源。 過於簡單？在SQLyog FAQ上，有一種觀點認為該軟體沒有正式歸檔的必要。當然，FAQ（常見問題解答）本身就是一種歸檔。SQLyog的界面非常直觀。我建議你列印一份MySOL文檔（包括SQL特殊語法擴展）。我就是這么做的，它只用了一個半英寸的活頁封面。 最後一步？FAQ還讓人想到一個讓人耳朵起了老繭卻又是正確的Occam's Razor准則——一切超出必要的復雜性都是沒有必要的。我之所以到處「推銷」這個工具，就是因為它可以為我們提供一個可以管理MySOL伺服器上許多資料庫的、簡單的、圖形化的界面。它的速度極快，並且它的拷貝很小（可以放在一張軟盤上）。
『陸』 數據分析過程如果用SQL語句進行統計如何實現
方法和詳細的操作步驟如下：
1、第一步，創建一個測試表，詳細代碼見下圖，轉到下面的步驟。
『柒』 數據分析人必掌握的資料庫語言-SQL指南第五期
本篇文章繼續圍繞SQL的語法重點為大家介紹 子查詢 的使用。
使用子查詢進行過濾
在SQL中SELECT語句用於查詢，之前所使用的所有SELECT語句都是簡單查詢，即從單個資料庫表中檢索數據的單條語句。然而SQL還可以創建子查詢，即嵌套在其他查詢中的查詢。
示例：
數據表：本次使用的資料庫表都是 關系表 。訂單存儲在兩個表中，每個訂單包含訂單編號、客戶ID、訂單日期，在Orders表中存儲為一行。各訂單的物品存儲在相關的OrderItems表中。Orders表不存儲顧客信息，只存儲顧客ID。顧客實際信息存儲在Customers表中。
若現在需要檢索出訂購RGAN01的所有顧客，應怎樣檢索？ 步驟如下：
① 檢索包含物品RGAN01的所有訂單的編號。
② 檢索具有前一步驟列出的訂單編號的所有顧客的ID。
③ 檢索前一步驟返回的所有顧客ID的顧客信息。
上述每個步驟都可 單獨作為一個查詢 來進行。
可將一條SELECT語句返回的結果用於另一條SELECT語句的WHERE子句，也可使用 子查詢 來將3個查詢組合成一條語句。
① 第一個語句含義明確，是對prod_id為RGAN01的所有訂單物品檢索其order_num列。
分析： 通過該語句知道了哪個訂單包含要檢索的物品。
② 下一步查詢與上述語句檢索出的訂單20007和20008相關的顧客ID。此處可利用IN子句。
下面可結合上述兩個查詢，將第一個查詢變為子查詢。
分析：在SELECT語句中， 子查詢總是從內向外處理 。在處理上述SELECT語句時，DBMS實際上執行了兩個操作。
首先執行了 圓括弧（）內的查詢 ，此查詢返回兩個訂單號： 20007 和 20008 .
接著這兩個值以IN操作符要求的逗號分隔的格式傳遞給外部查詢的WHERE子句。 外部查詢變為：
該語句檢索的結果和前面硬編碼WHERE子句返回的結果相同。
③ 由上述語句得出訂購物品RGAN01的所有顧客ID： 100004 和 100005 .下一步檢索這些顧客ID的顧客信息。
也可將其中的WHERE子句轉換為子查詢，就不用硬編碼這些顧客ID了。
分析： DBMS實際上必須執行三條SELECT語句才能完成上述語句。最裡面的子查詢返回訂單號，此列用於外面的子查詢的WHERE子句。外面的子查詢返回顧客ID列，此顧客ID列用於最外層查詢的WHERE子句。最外層查詢返回最終所需的數據。
由此可見，在WHERE子句中使用子查詢可編寫出功能強大靈活的SQL語句。對於能嵌套的子查詢的數目沒有限制，不過在實際應用中由於 性能的限制 ，不宜嵌套太多子查詢。
注意： 作為子查詢的SELECT語句只能查詢 單個列 ，檢索多個列將返回錯誤。另外使用子查詢並不總是執行該類數據檢索的最有效方法。
作為計算欄位使用子查詢
使用子查詢的另一方法是創建計算欄位。
示例： 需要顯示Customers表中每個顧客的訂單總數。訂單與相應的顧客ID都存儲在Orders表中。要執行這個操作，需要以下步驟：
① 從Customers表中檢索顧客列表。
② 對於檢索出的每個顧客，統計其在Orders表中的訂單數目。
這里我們可以應用之前介紹的 SELECT COUNT(*) 對表中的行進行計數，並通過一條WHERE子句來過濾某個特定的顧客ID，僅對該顧客的訂單進行計數。
如下對顧客1000001的訂單進行計數：
要對每個顧客執行COUNT(*)需要將其作為一個子查詢，如下：
分析： 該SELECT語句對Customers表中的每個顧客返回三列：cust_name、cust_state和orders。orders是一個 計算欄位 ，它由圓括弧中的子查詢建立。該子查詢對檢索出的每個顧客執行一次。此例中， 該子查詢執行了5次 ，因為檢索出了5個顧客。
子查詢中的WHERE子句與之前使用的WHERE子句略有不同，因為它使用了 完全限定列名 ，而不只是列名（cust_id）。它指定表名和列名（Orders.cust_id和Customers.cust_id）。下面的WHERE子句告訴SQL，比較Orders表中的cust_id和當前正從Customers表中檢索出的cust_id：
在有可能混淆列名時必須用一個 句點分隔表名和列名 。此例中，有兩個cust_id列：一個在Customers中，另一個在Orders中。若不採用完全限定名，DBMS會認為要對Orders表中的cust_id自身進行比較。因為：
上述語句總返回Orders表中訂單的總數，而該 結果不是我們想要的 ，如下：
由上可知，在構造語句時，若涉及到多個表，而不對同一列名加以區分則會引起DBMS拋出錯誤信息。
好的做法是，當在SELECT語句中操作多個表時， 使用完全限定列名來避免歧義 。
最後總結一下子查詢的特點：
① 子查詢必須括在圓括弧中。
② 子查詢的SELECT子句中只能有一個列，除非主查詢中有多個列，用於與子查詢選中的列相比較。
③ 子查詢不能使用ORDER BY，不過主查詢可以。在子查詢中，GROUP BY可以起到同ORDER BY相同的作用。
④ 返回多行數據的子查詢只能同多值操作符一起使用，比如IN操作符。
⑤ SELECT 列表中不能包含任何對BLOB、ARRAY、CLOB或者NCLOB類型值的引用。
⑥ 子查詢不能直接用在聚合函數中。
⑦ BETWEEN操作符不能同子查詢一起使用，但是BETWEEN操作符可以用在子查詢中。
以上便是本次介紹的全部內容，下篇文章將為大家講解 連接 和 高級連接 的使用。
我們下期再見！
『捌』 SQL資料庫語言分析
ALTER TABLE Customer_Data
ADD middle_initial char(1)
GO
這個本來就是一條執行語句 ...
意思是給表Customer_Data添加一個欄位名為middle_initial的欄位, 類型為CHAR,長度為1
至GO 寫不寫都行
『玖』 SQL語句執行流程與順序原理解析
SQL語句執行流程與順序原理解析
Oracle語句執行流程
第一步：客戶端把語句發給伺服器端執行
當我們在客戶端執行SQL語句時，客戶端會把這條SQL語句發送給伺服器端，讓伺服器端的進程來處理這語句。也就是說，Oracle 客戶端是不會做任何的操作，他的主要任務就是把客戶端產生的一些SQL語句發送給伺服器端。伺服器進程從用戶進程把信息接收到後， 在PGA 中就要此進程分配所需內存，存儲相關的信息，如：在會話內存存儲相關的登錄信息等。
雖然在客戶端也有一個資料庫進程，但是，這個進程的作用跟伺服器上的進程作用是不相同的，伺服器上的資料庫進程才會對SQL 語句進行相關的處理。不過，有個問題需要說明，就是客戶端的進程跟伺服器的進程是一一對應的。也就是說，在客戶端連接上伺服器後，在客戶端與伺服器端都會形成一個進程，客戶端上的我們叫做客戶端進程，而伺服器上的我們叫做伺服器進程。
第二步：語句解析
當客戶端把SQL語句傳送到伺服器後，伺服器進程會對該語句進行解析。這個解析的工作是在伺服器端所進行的，解析動作又可分為很多小動作。
1）查詢高速緩存（library cache）
伺服器進程在接到客戶端傳送過來的SQL語句時，不會直接去資料庫查詢。伺服器進程把這個SQL語句的字元轉化為ASCII等效數字碼，接著這個ASCII碼被傳遞給一個HASH函數，並返回一個hash值，然後伺服器進程將到shared pool中的library cache（高速緩存）中去查找是否存在相同的hash值。如果存在，伺服器進程將使用這條語句已高速緩存在SHARED POOL的library cache中的已分析過的版本來執行，省去後續的解析工作，這便是軟解析。若調整緩存中不存在，則需要進行後面的步驟，這便是硬解析。硬解析通常是昂貴的操作，大約占整個SQL執行的70%左右的時間，硬解析會生成執行樹，執行計劃，等等。
所以，採用高速數據緩存的話，可以提高SQL 語句的查詢效率。其原因有兩方面：一方面是從內存中讀取數據要比從硬碟中的數據文件中讀取數據效率要高，另一方面也是因為避免語句解析而節省了時間。
不過這里要注意一點，這個數據緩存跟有些客戶端軟體的數據緩存是兩碼事。有些客戶端軟體為了提高查詢效率，會在應用軟體的客戶端設置數據緩存。由於這些數據緩存的存在，可以提高客戶端應用軟體的查詢效率。但是，若其他人在伺服器進行了相關的修改，由於應用軟體數據緩存的存在，導致修改的數據不能及時反映到客戶端上。從這也可以看出，應用軟體的數據緩存跟資料庫伺服器的高速數據緩存不是一碼事。
2）語句合法性檢查（data dict cache）
當在高速緩存中找不到對應的SQL語句時，則伺服器進程就會開始檢查這條語句的合法性。這里主要是對SQL語句的語法進行檢查，看看其是否合乎語法規則。如果伺服器進程認為這條SQL語句不符合語法規則的時候，就會把這個錯誤信息反饋給客戶端。在這個語法檢查的過程中，不會對SQL語句中所包含的表名、列名等等進行檢查，只是檢查語法。
3）語言含義檢查（data dict cache）
若SQL 語句符合語法上的定義的話，則伺服器進程接下去會對語句中涉及的表、索引、視圖等對象進行解析，並對照數據字典檢查這些對象的名稱以及相關結構，看看這些欄位、表、視圖等是否在資料庫中。如果表名與列名不準確的話，則資料庫會就會反饋錯誤信息給客戶端。
所以，有時候我們寫select語句的時候，若語法與表名或者列名同時寫錯的話，則系統是先提示說語法錯誤，等到語法完全正確後再提示說列名或表名錯誤。
4）獲得對象解析鎖（control structer）
當語法、語義都正確後，系統就會對我們需要查詢的對象加鎖。這主要是為了保障數據的一致性，防止我們在查詢的過程中，其他用戶對這個對象的結構發生改變。
5）數據訪問許可權的核對（data dict cache）
當語法、語義通過檢查之後，客戶端還不一定能夠取得數據，伺服器進程還會檢查連接用戶是否有這個數據訪問的許可權。若用戶不具有數據訪問許可權的話，則客戶端就不能夠取得這些數據。要注意的是資料庫伺服器進程先檢查語法與語義，然後才會檢查訪問許可權。
6）確定最佳執行計劃
當語法與語義都沒有問題許可權也匹配，伺服器進程還是不會直接對資料庫文件進行查詢。伺服器進程會根據一定的規則，對這條語句進行優化。在執行計劃開發之前會有一步查詢轉換，如：視圖合並、子查詢解嵌套、謂語前推及物化視圖重寫查詢等。為了確定採用哪個執行計劃，Oracle還需要收集統計信息確定表的訪問聯結方法等，最終確定可能的最低成本的執行計劃。
不過要注意，這個優化是有限的。一般在應用軟體開發的過程中，需要對資料庫的sql語句進行優化，這個優化的作用要大大地大於伺服器進程的自我優化。
當伺服器進程的優化器確定這條查詢語句的最佳執行計劃後， 就會將這條SQL語句與執行計劃保存到數據高速緩存（library cache）。如此，等以後還有這個查詢時，就會省略以上的語法、語義與許可權檢查的步驟，而直接執行SQL語句，提高SQL語句處理效率。
第三步：綁定變數賦值
如果SQL語句中使用了綁定變數，掃描綁定變數的聲明，給綁定變數賦值，將變數值帶入執行計劃。若在解析的第一個步驟，SQL在高速緩沖中存在，則直接跳到該步驟。
第四步：語句執行
語句解析只是對SQL語句的語法進行解析，以確保伺服器能夠知道這條語句到底表達的是什麼意思。等到語句解析完成之後，資料庫伺服器進程才會真正的執行這條SQL語句。
對於SELECT語句：
1）首先伺服器進程要判斷所需數據是否在db buffer存在，如果存在且可用，則直接獲取該數據而不是從資料庫文件中去查詢數據，同時根據LRU 演算法增加其訪問計數；
2）若數據不在緩沖區中，則伺服器進程將從資料庫文件中查詢相關數據，並把這些數據放入到數據緩沖區中（buffer cache）。
其中，若數據存在於db buffer，其可用性檢查方式為：查看db buffer塊的頭部是否有事務，如果有事務，則從回滾段中讀取數據；如果沒有事務，則比較select的scn和db buffer塊頭部的scn，如果前者小於後者，仍然要從回滾段中讀取數據；如果前者大於後者，說明這是一非臟緩存，可以直接讀取這個db buffer塊的中內容。
對於DML語句（insert、delete、update）：
1）檢查所需的資料庫是否已經被讀取到緩沖區緩存中。如果已經存在緩沖區緩存，則直接執行步驟3；
2）若所需的資料庫並不在緩沖區緩存中，則伺服器將數據塊從數據文件讀取到緩沖區緩存中；
3）對想要修改的表取得的數據行鎖定（Row Exclusive Lock），之後對所需要修改的數據行取得獨占鎖；
4）將數據的Redo記錄復制到redo log buffer；
5）產生數據修改的undo數據；
6）修改db buffer；
7）dbwr將修改寫入數據文件；
其中，第2步，伺服器將數據從數據文件讀取到db buffer經經歷以下步驟：
1）首先伺服器進程將在表頭部請求TM鎖（保證此事務執行過程其他用戶不能修改表的結構），如果成功加TM鎖，再請求一些行級鎖（TX鎖），如果TM、TX鎖都成功加鎖，那麼才開始從數據文件讀數據。
2）在讀數據之前，要先為讀取的文件准備好buffer空間。伺服器進程需要掃描LRU list尋找free db buffer，掃描的過程中，伺服器進程會把發現的所有已經被修改過的db buffer注冊到dirty list中。如果free db buffer及非臟數據塊緩沖區不足時，會觸發dbwr將dirty buffer中指向的緩沖塊寫入數據文件，並且清洗掉這些緩沖區來騰出空間緩沖新讀入的數據。
3）找到了足夠的空閑buffer，伺服器進程將從數據文件中讀入這些行所在的每一個數據塊（db block）（DB BLOCK是ORACLE的最小操作單元，即使你想要的數據只是DB BLOCK中很多行中的一行或幾行，ORACLE也會把這個DB BLOCK中的所有行都讀入Oracle DB BUFFER中）放入db buffer的空閑的區域或者覆蓋已被擠出LRU list的非臟數據塊緩沖區，並且排列在LRU列表的頭部，也就是在數據塊放入db buffer之前也是要先申請db buffer中的鎖存器，成功加鎖後，才能讀數據到db buffer。
若數據塊已經存在於db buffer cache（有時也稱db buffer或db cache），即使在db buffer中找到一個沒有事務，而且SCN比自己小的非臟緩存數據塊，伺服器進程仍然要到表的頭部對這條記錄申請加鎖，加鎖成功才能進行後續動作，如果不成功，則要等待前面的進程解鎖後才能進行動作（這個時候阻塞是tx鎖阻塞）。
在記redo日誌時，其具體步驟如下：
1）數據被讀入到db buffer後，伺服器進程將該語句所影響的並被讀入db buffer中的這些行數據的rowid及要更新的原值和新值及scn等信息從PGA逐條的寫入redo log buffer中。在寫入redo log buffer之前也要事先請求redo log buffer的鎖存器，成功加鎖後才開始寫入。
2）當寫入達到redo log buffer大小的三分之一或寫入量達到1M或超過三秒後或發生檢查點時或者dbwr之前發生，都會觸發lgwr進程把redo log buffer的數據寫入磁碟上的redo file文件中（這個時候會產生log file sync等待事件）。
3）已經被寫入redo file的redo log buffer所持有的鎖存器會被釋放，並可被後來的寫入信息覆蓋，redo log buffer是循環使用的。Redo file也是循環使用的，當一個redo file寫滿後，lgwr進程會自動切換到下一redo file（這個時候可能出現log file switch（check point complete）等待事件）。如果是歸檔模式，歸檔進程還要將前一個寫滿的redo file文件的內容寫到歸檔日誌文件中（這個時候可能出現log file switch（archiving needed）。
在為事務建立undo信息時，其具體步驟如下：
1）在完成本事務所有相關的redo log buffer之後，伺服器進程開始改寫這個db buffer的塊頭部事務列表並寫入scn（一開始scn是寫在redo log buffer中的，並未寫在db buffer）。
2）然後包含這個塊的頭部事務列表及scn信息的數據副本放入回滾段中，將這時回滾段中的信息稱為數據塊的「前映像」，這個「前映像」用於以後的回滾、恢復和一致性讀。（回滾段可以存儲在專門的回滾表空間中，這個表空間由一個或多個物理文件組成，並專用於回滾表空間，回滾段也可在其它表空間中的數據文件中開辟）。
在修改信息寫入數據文件時，其具體步驟如下：
1）改寫db buffer塊的數據內容，並在塊的頭部寫入回滾段的地址。
2）將db buffer指針放入dirty list。如果一個行數據多次update而未commit，則在回滾段中將會有多個「前映像」，除了第一個「前映像」含有scn信息外，其他每個"前映像"的頭部都有scn信息和"前前映像"回滾段地址。一個update只對應一個scn，然後伺服器進程將在dirty list中建立一條指向此db buffer塊的指針（方便dbwr進程可以找到dirty list的db buffer數據塊並寫入數據文件中）。接著伺服器進程會從數據文件中繼續讀入第二個數據塊，重復前一數據塊的動作，數據塊的讀入、記日誌、建立回滾段、修改數據塊、放入dirty list。
3）當dirty queue的長度達到閥值（一般是25%），伺服器進程將通知dbwr把臟數據寫出，就是釋放db buffer上的鎖存器，騰出更多的free db buffer。前面一直都是在說明oracle一次讀一個數據塊，其實oracle可以一次讀入多個數據塊（db_file_multiblock_read_count來設置一次讀入塊的個數）
當執行commit時，具體步驟如下：
1）commit觸發lgwr進程，但不強制dbwr立即釋放所有相應db buffer塊的鎖。也就是說有可能雖然已經commit了，但在隨後的一段時間內dbwr還在寫這條sql語句所涉及的數據塊。表頭部的行鎖並不在commit之後立即釋放，而是要等dbwr進程完成之後才釋放，這就可能會出現一個用戶請求另一用戶已經commit的資源不成功的現象。
2）從Commit和dbwr進程結束之間的時間很短，如果恰巧在commit之後，dbwr未結束之前斷電，因為commit之後的數據已經屬於數據文件的內容，但這部分文件沒有完全寫入到數據文件中。所以需要前滾。由於commit已經觸發lgwr，這些所有未來得及寫入數據文件的更改會在實例重啟後，由smon進程根據重做日誌文件來前滾，完成之前commit未完成的工作（即把更改寫入數據文件）。
3）如果未commit就斷電了，因為數據已經在db buffer更改了，沒有commit，說明這部分數據不屬於數據文件。由於dbwr之前觸發lgwr也就是只要數據更改，（肯定要先有log）所有dbwr在數據文件上的修改都會被先一步記入重做日誌文件，實例重啟後，SMON進程再根據重做日誌文件來回滾。
其實smon的前滾回滾是根據檢查點來完成的，當一個全部檢查點發生的時候，首先讓LGWR進程將redologbuffer中的所有緩沖（包含未提交的重做信息）寫入重做日誌文件，然後讓dbwr進程將dbbuffer已提交的緩沖寫入數據文件（不強制寫未提交的）。然後更新控制文件和數據文件頭部的SCN，表明當前資料庫是一致的，在相鄰的兩個檢查點之間有很多事務，有提交和未提交的。
當執行rollback時，具體步驟如下：
伺服器進程會根據數據文件塊和db buffer中塊的頭部的事務列表和SCN以及回滾段地址找到回滾段中相應的修改前的副本，並且用這些原值來還原當前數據文件中已修改但未提交的改變。如果有多個」前映像「，伺服器進程會在一個「前映像」的頭部找到「前前映像」的回滾段地址，一直找到同一事務下的最早的一個「前映像」為止。一旦發出了commit，用戶就不能rollback，這使得commit後dbwr進程還沒有全部完成的後續動作得到了保障。
第五步：提取數據
當語句執行完成之後，查詢到的數據還是在伺服器進程中，還沒有被傳送到客戶端的用戶進程。所以，在伺服器端的進程中，有一個專門負責數據提取的一段代碼。他的作用就是把查詢到的數據結果返回給用戶端進程，從而完成整個查詢動作。
從這整個查詢處理過程中，我們在資料庫開發或者應用軟體開發過程中，需要注意以下幾點：
一是要了解資料庫緩存跟應用軟體緩存是兩碼事情。資料庫緩存只有在資料庫伺服器端才存在，在客戶端是不存在的。只有如此，才能夠保證資料庫緩存中的內容跟資料庫文件的內容一致。才能夠根據相關的規則，防止數據臟讀、錯讀的發生。而應用軟體所涉及的數據緩存，由於跟資料庫緩存不是一碼事情，所以，應用軟體的數據緩存雖然可以提高數據的查詢效率，但是，卻打破了數據一致性的要求，有時候會發生臟讀、錯讀等情況的發生。所以，有時候，在應用軟體上有專門一個功能，用來在必要的時候清除數據緩存。不過，這個數據緩存的清除，也只是清除本機上的數據緩存，或者說，只是清除這個應用程序的數據緩存，而不會清除資料庫的數據緩存。
二是絕大部分SQL語句都是按照這個處理過程處理的。我們DBA或者基於Oracle資料庫的開發人員了解這些語句的處理過程，對於我們進行涉及到SQL語句的開發與調試，是非常有幫助的。有時候，掌握這些處理原則，可以減少我們排錯的時間。特別要注意，資料庫是把數據查詢許可權的審查放在語法語義的後面進行檢查的。所以，有時會若光用資料庫的許可權控制原則，可能還不能滿足應用軟體許可權控制的需要。此時，就需要應用軟體的前台設置，實現許可權管理的要求。而且，有時應用資料庫的許可權管理，也有點顯得繁瑣，會增加伺服器處理的工作量。因此，對於記錄、欄位等的查詢許可權控制，大部分程序涉及人員喜歡在應用程序中實現，而不是在資料庫上實現。
Oracle SQL語句執行順序
(8)SELECT (9) DISTINCT (11) <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
1）FROM：對FROM子句中的表執行笛卡爾積(交叉聯接)，生成虛擬表VT1。
2）ON：對VT1應用ON篩選器，只有那些使為真才被插入到TV2。
3）OUTER (JOIN):如果指定了OUTER JOIN(相對於CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行將作為外部行添加到VT2，生成TV3。如果FROM子句包含兩個以上的表，則對上一個聯接生成的結果表和下一個表重復執行步驟1到步驟3，直到處理完所有的表位置。
4）WHERE：對TV3應用WHERE篩選器，只有使為true的行才插入TV4。
5）GROUP BY：按GROUP BY子句中的列列表對TV4中的行進行分組，生成TV5。
6）CUTE|ROLLUP：把超組插入VT5，生成VT6。
7）HAVING：對VT6應用HAVING篩選器，只有使為true的組插入到VT7。
8）SELECT：處理SELECT列表，產生VT8。
9）DISTINCT：將重復的行從VT8中刪除，產品VT9。
10）ORDER BY：將VT9中的行按ORDER BY子句中的列列表順序，生成一個游標(VC10)，生成表TV11，並返回給調用者。
以上每個步驟都會產生一個虛擬表，該虛擬表被用作下一個步驟的輸入。這些虛擬表對調用者(客戶端應用程序或者外部查詢)不可用。只有最後一步生成的表才會會給調用者。如果沒有在查詢中指定某一個子句，將跳過相應的步驟。
『拾』 如何用SQL分析電商用戶行為數據（案例）
本文以「淘寶用戶行為數據集」的分析全過程為例，展示數據分析的全過程
——使用工具：MySQL，Excel，Navicat，PowerBI
——分析類型：描述分析，診斷分析
——分析方法：漏斗分析，用戶路徑分析，RFM用戶價值分析，活躍/存留分析，帕累托分析，假設驗證分析。
（考慮到閱讀體驗文章中只放了SQL截圖，如需PDF版本，再公眾號後台回復「用戶行為分析」領取）
（目錄如下）
1.分析流程和方法
當沒有清晰的數據看板時我們需要先清洗雜亂的數據，基於分析模型做可視化，搭建描述性的數據看板。
然後基於描述性的數據挖掘問題，提出假設做優化，或者基於用戶特徵數據進行預測分析找規律，基於規律設計策略。簡單來說：
——描述性分析就是：「畫地圖」
——診斷性分析就是：「找問題」
——預測性分析就是 ：「找規律」
在數據分析中有兩個典型的場景：
一種是有數據，沒有問題：需要先整體分析數據，然後再根據初步的描述分析，挖掘問題做診斷性分析，提出假設，設計策略解決問題。
另一種是已經發現了問題，或者已經有了假設，這種做數據分析更偏向於驗證假設。
2.淘寶用戶行為分析
本次是對「淘寶用戶行為數據集」進行分析，在分析之前我們並不知道有什麼問題，所以需要先進行描述性分析，分析數據挖掘問題。
我們首先來看下這個數據集的元數據：
根據以上數據欄位我們可以拿用戶行為為主軸從縱深方向提出一些問題，然後再從數據中找答案
縱向：
——這個數據集中用戶的日活躍和周活躍時間有什麼規律嗎？
——在當日活躍的用戶次日，三日，四日……還有多少活躍？
深向：
——用戶從瀏覽到購買的整體轉化率怎麼樣？
——用戶從瀏覽到購買的路徑是怎麼樣子的？
——平台主要會給用戶推送什麼商品？
——用戶喜歡什麼類目？喜歡什麼商品？
——怎麼判斷哪些是高價值用戶 ？
下面是叮當整理的常用分析方法：
我們可以給前面的問題匹配一下分析方法，便於後面的分析：
為了便於後面的數據分析，在分析之前我們需要先對做一下清洗
看元數據（欄位解釋，數據來源，數據類型，數據量……）初步發現問題為之後的處理做准備。
確定缺失值范圍，去除不需要欄位，填充缺失內容
根據元數據格式和後續分析需要的格式對數據進行處理
去除重復值，異常值
——去除重復值：並把用戶ID,商品ID，時間戳設置為主鍵
——異常值處理：查詢並刪除2017年11月25日至2017年12月3日之外的數據
查詢並刪除小於2017-11-25的
——驗證數據：
——分析思路：
——SQL提數：
——Excel可視化：
活躍曲線整體為上升狀態，同為周六日，12月2號，3號相比11月25日，26日活躍度更高。
用戶在周六周日相比其他時間更活躍（周六周日為休息日，用戶有更多時間）
一天內用戶活躍的最高峰期為21點（用戶在這個時間段空閑較多）
——分析思路：
——SQL提數：
列出每用戶每天及當天後面又活躍的日期，並創建「活躍時間間隔表」用於後面求次日存留，三日存留……
對「活躍時間間隔表視圖」引用進行分組統計，計算每日存留人數並創建視圖
對存留人數表進行計算，統計活躍用戶留存率
——Excel可視化：
——分析思路：
——SQL提數：
-把各種用戶行為分離出來並創建視圖方便後續查詢用戶行為數據
查詢整體數據漏斗
——Excel可視化：
用戶從瀏覽到購買整體轉化率2.3%，具體主要在哪個環節流失還需要再細分用戶路徑分析
——分析思路：
——SQL提數：
——PowerBI可視化：
用戶從瀏覽到購買的路徑主要有4條，路徑越長轉化率越底
路徑1：瀏覽→購買：轉化率1.45%
路徑2：瀏覽→加購物車→購買：轉化率0.33
路徑3：瀏覽→收藏→購買：轉化率0.11%
路徑4：瀏覽→收藏→加購物車→購買：轉化率0.03%
——分析思路：
——SQL提數：
——Excel可視化：
——描述性分析：
瀏覽量top100的商品瀏覽量呈階梯分布，越靠前的階梯之間的落差相對越大在這個階梯中的商品越少，越靠後商品瀏覽量階梯之間的落差相對越小，同階梯內的商品越多。
瀏覽量TOP100的商品所屬類目中，4756105，3607361，4357323三個類目瀏覽量遠超其他類目。
——分析思路：
——SQL提數：
查詢計算商品轉化率，升序排列，取前100個
——Excel可視化：
——描述性分析：
從商品看：有17款商品轉化率超過了1。
從類目看：這些商品所屬類目分布均勻，除965809，4801426，2735466，2640118，5063620，4789432，2945933這7個類目之外，其他類目都只有一個商品在轉化率TOP100的商品中。
——分析思路：
用戶價值分析常用的分析方式是RFM模型
本次分析中的R,F,M具體定義（僅用於演示分析方法，無實際業務參考價值）：
——SQL取數與分析：
1）建立打分標准：先計算R,F的值，並排序，根據R,F值最大值和最小值得區間設計本次得打分標准
-查詢並計算R，F值創建視圖
-引用RF數值表，分別查詢R,F的最大值和最小值
-結合人工瀏覽的建立打分標准
2）給R，F按價值打分
3）計算價值的平均值
4）用平均值和用戶分類規則表比較得出用戶分類
——Excel可視化
通過描述性分析得到可視化的數據後我們一般會先看一下是否符合業務常識
如果符合常識接下來我們會通過與行業平均數據和本產品的同比環比對比看是否正常，如果不正常就要找原因，設計解決方案，如果正常那就看是否有可以優化的地方。
我們首先來看一下這些描述性分析是否符合業務常識和指標是否正常：
1.活躍曲線整體為上升狀態，同為周六日，12月2號，3號相比11月25日，26日活躍度更高。
2.用戶在周六周日相比其他時間更活躍
3.一天內用戶活躍的最高峰期為21點
4.從2017年11月15日致2017年12月3日，活躍用戶新增38%
5.從2017年11月15日致2017年12月3日，活躍用戶次日留存增長18.67%，當日的活躍用戶留存也在快速增長，第七日留存比次日留存高18.56%。
6.用戶從瀏覽到購買整體轉化率2.3%
7.用戶從瀏覽到購買的路徑主要有4條，路徑越長轉化率越低。
8.瀏覽量top100的商品瀏覽量呈階梯分布，越靠前的階梯之間的落差相對越大在這個階梯中的商品越少，越靠後商品瀏覽量階梯之間的落差相對越小，同階梯內的商品越多。
9.瀏覽量TOP100的商品所屬類目中，4756105，3607361，4357323三個類目瀏覽量遠超其他類目。
10.從商品看：有17款商品轉化率超過了1。
11.從類目看：這些商品所屬類目分布均勻，除965809，4801426，2735466，2640118，5063620，4789432，2945933這7個類目之外，其他類目都只有一個商品在轉化率TOP100的商品中。
根據以上診斷分析我們梳理出了以下假設，做假設驗證。
假設1：這些商品中有高轉化率的爆款商品
對比瀏覽量TOP5的商品，發現這些商品轉化率在同一類目下並不高，假設不成立
假設2：4756105，3607361，4357323三個類目屬於高頻剛需類目
-創建類目購買頻次表
-計算類目購買頻次平均值
-查詢4756105，3607361，4357323三個類目的購買頻次
4756105，3607361，4357323三個類目的用戶購買頻次明顯高於平均值，假設成立
假設3：有部分用戶是未點擊商詳直接從收藏和購物車購買的。
用戶不是直接從收藏和購物車購買的，只是後續復購未點擊商詳，假設不成立
假設4：淘寶推薦的商品主要是「同一類目下的高轉化商品」
用Excel對瀏覽量TOP100的商品ID和轉化率TOP100的商品ID進行去重，結果無重復值，假設不成立
3.結論：
1）用戶活躍：用戶活躍曲線整體呈上升趨勢，在一周中周六，周日活躍度比平時更高，在一天中用戶活躍曲線從凌晨4點開始往上升，在中午12點和下午5~6點有兩個小低谷（吃飯），到晚上9點時活躍度達到頂峰。
2）用戶留存：從2017年11月15日致2017年12月3日的用戶留存數據來看，淘寶的用戶留存數據較好，活躍用戶次日留存增長18.67%，當日的活躍用戶留存也在快速增長，第七日留存比次日留存高18.56%。
3）用戶轉化：整體轉化2.3%，用戶從瀏覽到購買的路徑主要有4條，路徑越長轉化率越低。
4）平台推薦與用戶偏好：從數據集中的數據來看，排除用戶興趣偏好標簽，淘寶給用戶用戶推送的商品主要是高頻剛需的類目，促使用戶復購，流量迴流平台。
以上結論受數據量和數據類型的影響，並不一定準確，僅用來練習數據分析方法。
（考慮到閱讀體驗文章中只放了SQL截圖，如需PDF版本，再公眾號後台回復「用戶行為分析」領取）