靈魂100問學習

目錄

1.Mysql索引

1.型別：普通索引、唯一索引、主鍵索引、組合索引、全文索引
2.建立方法：ａ.　建表的時候一起建立。b. 建表後，直接建立索引c. 修改表結構
主鍵索引只有（a.c)
3.限制：
普通索引（最基本的索引，它沒有任何限制，用於加速查詢。）
唯一索引（索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。）
主鍵索引（是一種特殊的唯一索引，一個表只能有一個主鍵，不允許有空值。一般是在建表的時候同時建立主鍵索引。）
組合索引（指多個欄位上建立的索引，只有在查詢條件中使用了建立索引時的第一個欄位，索引才會被使用。使用組合索引時遵循最左字首集合

2.OLAP和OLTP的區別

聯機事務處理OLTP（on-line transaction processing）:傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。
聯機分析處理OLAP（On-Line Analytical Processing）:資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。
下表列出了OLTP與OLAP之間的比較。
操作特點、響應速度、吞吐量、併發訪問量、資源消耗、索引型別、索引量

3.資料庫

1. 什麼是資料庫？
   資料庫=多張表+各表之間的關係
   
   2. 資料庫表長什麼樣？
   資料庫中每個表由一個名字標識。表包含帶有列名的列，和記錄資料的行。
   ID是資料庫中重要的概念，叫做唯一識別符號或者主鍵，用來表示資料的唯一性。
2. 資料庫裡各個表之間如何建立聯絡呢？
   資料庫中，如果你要關聯其他表，一般會以「表名_ID」作為聯接。
   聯絡就是資料能夠對應匹配，在資料庫中正式名稱叫聯接，對應的操作叫做join。
   4.資料庫和SQL是什麼關係？
   資料庫裡面放著資料，而SQL是用來操作資料庫裡資料的語言（工具）。
   作者：猴子聊人物
   連結：https://www.jianshu.com/p/7b55d958860b
   來源：簡書
   著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。
   資料庫模型有三種，分別為層次式資料庫，網路式資料庫和關係型資料庫。而在當今的網際網路中，最常用的資料庫模型主要是兩種，即關係型資料庫和非關係型資料庫
   1）鍵值(Key-Value)儲存資料庫
   鍵值資料庫就類似傳統語言中使用的雜湊表。可以通過key來新增，查詢或者刪除資料（增刪查），因為使用key主鍵訪問，所以會獲得很高的效能及擴充套件性。
   鍵值（key-value）資料庫主要是使用一個雜湊表，這個表中有一個特定的鍵和一個指標指向特定的資料。Key/value模型對於IT系統來說的優勢在於簡單，易部署，高併發。
   經典產品：Memcached，redis，memcacheDB，Berkeley DB
   2）列儲存（column-oriented）資料庫
   列儲存資料庫將資料存在列族（column family）中，一個列族儲存經常被一起查詢的相關資料。舉個例子，如果我們有一個person類，我們通過會一起查詢他們得姓名和年齡而不是薪資。這種情況下，名字和年齡就會被放入一個列族中，而薪資則在另一個列族中。而薪資則在另一個列族中。
   這部分資料庫通常是用來應對分散式儲存的海量資料。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的
   典型產品：Cassandra,HBase 基於列的儲存系統
   3)面向文件（Document-Oriented）資料庫
   文件型資料庫的靈感是來自於Lotus Notes辦公軟體的，而且它同第一種鍵值儲存相類似。該型別的資料模型是版本化的文件，半結構化的文件以特定的格式儲存，比如JSON.文件型資料庫可以看作是鍵值資料庫的升級版，允許之間巢狀鍵值。而且文件型資料庫比鍵值資料庫的查詢效率更高。
   面向檔案資料庫會將資料以文件的形式儲存。每個文件都是自包含的資料單元，是一系列資料項的集合。每個資料項都有一個名稱與對應的值，值既可以是簡單的資料型別，如字串，數字和日期等；也可以是複雜的型別，如有序列表和關聯物件。資料儲存的最小單位是文件，同一個表中儲存的文件屬性可以是不同的，資料可以使用XML，JSON或者JSNOB等多種形式儲存。
   典型產品：MongoDB，GouchDB
   4)圖形（Graph）資料庫
   圖形資料庫允許我們將資料以圖的方式儲存。實體會被作為頂點，而實體之間的關係則會被作為邊。比如我們有三個實體，Steve jobs，Apple和Next，則會有兩個“Founded by”的邊將Apple和Next連線到Steve Jobs。
   圖形結構的資料庫同其他行列以及剛性結構的SQL資料庫不同，它是使用靈活的圖形模型，並且能夠擴充套件到多個伺服器上。NoSQL資料庫沒有標準的查詢語言（SQL），因此進行資料庫查詢需要制定資料型別。許多NoSQL資料庫都有RSET式的資料介面或者查詢API。
   典型產品：Neo4J,InfoGrid

4.資料庫、資料倉庫的區別

聯絡：資料倉庫是由資料庫以一種方式組織起來的。
區別：
（1）資料庫強調正規化，儘可能減少冗餘；
資料倉庫強調查詢分析的速度，優化讀取的操作，主要目的是做大量資料的查詢。
(2) 資料庫是行儲存，資料倉庫是列儲存。
（3）資料庫面向事務的，線上交易處理（OLTP）
資料倉庫是面向主題的、整合、相對穩定、反應歷史變化，儲存歷史資料（OLAP）。
（4）資料倉庫定期寫入新資料，而不覆蓋原有資料，而是給資料加上時間戳。
（5）資料倉庫兩個基本元素：事實表和維度表
事實表儲存要查詢的資料；維度是看待問題的角度，如時間、部門等。

5.行儲存、列儲存的區別

行儲存：傳統資料庫的儲存方式，同一張表內的資料存放在一起，插入更新快。
缺點：選擇(Selection)時即使只涉及某幾列，所有資料也都會被讀取。
列儲存：優點：查詢時只有涉及到的列會被讀取，投影很高效，任何列都能作為索引。
缺點：選擇完成時，需要對選擇的列進行重新組裝； INSERT/UPDATE比較慢

6.外部表和內部表有什麼不同？

1. 定義：未被external修飾的是內部表（managed table），被external修飾的為外部表（external table）；
2. 區別(4個）：
   內部表資料由Hive自身管理，外部表資料由HDFS管理；
   內部表資料儲存的位置是hive.metastore.warehouse.dir（預設：/user/hive/warehouse），外部表資料的儲存位置由自己制定；
   刪除內部表會直接刪除元資料（metadata）及儲存資料；刪除外部表僅僅會刪除元資料，HDFS上的檔案並不會被刪除（這樣外部表相對來說更加安全些，資料組織也更加靈活，方便共享源資料。）；
   對內部表的修改會將修改直接同步給元資料，而對外部表的表結構和分割槽進行修改，則需要修復（MSCK REPAIR TABLE table_name;）
3. 需要注意的是
   傳統資料庫對錶資料驗證是 schema on write（寫時模式），而 Hive 在load時是不檢查資料是否符合schema的，hive 遵循的是 schema on read（讀時模式），只有在讀的時候hive才檢查、解析具體的資料欄位、schema。
4. 讀時模式VS寫時模式
   讀時模式的優勢是load data 非常迅速，因為它不需要讀取資料進行解析，僅僅進行檔案的複製或者移動。
   寫時模式的優勢是提升了查詢效能，因為預先解析之後可以對列建立索引，並壓縮，但這樣也會花費要多的載入時間。
5. 生產環境中為什麼建議使用外部表？

1. 因為外部表不會載入資料到hive，減少資料傳輸、資料還能共享。
2. hive不會修改資料，所以無需擔心資料的損壞
3. 刪除表時，只刪除表結構、不刪除資料。
   參考：

7.資料傾斜如何處理？

1.什麼是資料傾斜？
資料分配嚴重不均就會產生資料傾斜。
資料傾斜，指的是並行處理的過程中，某些分割槽或節點處理的數據，顯著高於其他分割槽或節點，導致這部分的資料處理任務比其他任務要大很多，從而成為這個階段執行最慢的部分，進而成為整個作業執行的瓶頸，甚至直接導致作業失敗。
2.資料傾斜的危害
（1）任務長時間掛起，資源利用率低下
（2）引發記憶體溢位，導致任務失敗
（3）作業執行時間超出預期，導致後續依賴作業結果的作業出錯
3.資料傾斜的原因
（1）讀入資料的時候就是傾斜的
讀入資料是計算任務的開始，但是往往這個階段就可能已經開始出現問題了。
對於一些本身就可能傾斜的資料來源，在讀入階段就可能出現個別partition執行時長過長或直接失敗，如讀取id分佈跨度較大的mysql數據、partition分配不均的kafka資料或不可分割的壓縮檔案。
這些場景下，資料在讀取階段或者讀取後的第一個計算階段，就會容易執行過慢或報錯。
（2）shuffle產生傾斜
在shuffle階段造成傾斜，在實際的工作中更加常見，比如特定key值數量過多，導致join發生時，大量資料湧向一個節點，導致資料嚴重傾斜，個別節點的讀寫壓力是其他節點的好幾倍，容易引發OOM錯誤。
（3）過濾導致傾斜
有些場景下，資料原本是均衡的，但是由於進行了一系列的資料剔除操作，可能在過濾掉大量資料後，造成資料的傾斜。
例如，大部分節點都被過濾掉了很多資料，只剩下少量資料，但是個別節點的資料被過濾掉的很少，保留著大部分的資料。這種情況下，一般不會OOM，但是傾斜的資料可能會隨著計算逐漸累積，最終引發問題。
4.如何預防或解決資料傾斜問題？
（1）儘量保證資料來源是均衡的
程式讀入的資料來源通常是上個階段其他作業產生的，那麼我們在上個階段作業生成資料時，就要注意這個問題，儘量不要給下游作業埋坑。
小建議：在程式輸出寫檔案時，儘量不要用coalesce，而是用repartition，這樣寫出的資料，各檔案大小往往是均衡的。
（2）對大資料集做過濾，結束後做repartition
對比較大的資料集做完過濾後，如果過濾掉了絕大部分資料，在進行下一步操作前，最好可以做一次repartition，讓資料重回均勻分佈的狀態，否則失衡的資料集，在進行後續計算時，可能會逐漸累積傾斜的狀態，容易產生錯誤。
（3）對小表進行廣播
如果兩個資料量差異較大的表做join時，發生資料傾斜的常見解決方法，是將小表廣播到每個節點去，這樣就可以實現map端join，從而省掉shuffle，避免了大量資料在個別節點上的匯聚，執行效率也大大提升。
（4）編碼時要注意，不要人為造成傾斜
（5）join前優化
個別場景下，兩個表join，某些特殊key值可能很多，很容易產生資料傾斜，這時可以根據實際計算進行join前優化。
如計算是先join後根據key聚合，那可以改為先根據key聚合然後再join。又如，需求是join後做distinct操作，在不影響結果的前提下，可以改為先distinct，然後再join。這些措施都是可以有效避免重複key過多導致join時傾斜。
4.6.具體問題具體分析
例如，讀入mysql資料時傾斜，這通常是由於mysql的id分佈嚴重不均，中間存在跨度很大的區間造成的。解決方法有兩種，一是加大讀取時的分割槽數，將傾斜的區間劃分開；另一種是，先把id取出來進行等寬切割，確保每個區段的id數量一致，之後再對各區間進行資料讀取。
參考：

8.關係型資料庫通過索引提升查詢效率的背後原理 ？

1. 如果沒有索引，資料庫引擎需要通過全表掃描來查詢資料，這會產生大量的磁碟IO。
2. 關係型資料庫使用B+樹構建索引來加速加快查詢。B+樹是一種二叉查詢樹（每個節點的鍵值必須：比儲存在左子樹的任何鍵值都要大，比儲存在右子樹的任何鍵值都要小），這樣隨機查詢某個鍵值時可以通過從根節點執行二叉查詢來加速查詢，查詢成本取決於樹的層數。
3. 針對範圍查詢和排序的優化：在每個葉子節點儲存其下一個葉子節點的指標，這樣當指定範圍範圍查詢時，先從根節點根據範圍的左值找到其葉子節點，之後通過向後遍歷葉子節點即可找到對應範圍右值，這樣可以加速範圍查詢、排序、分組等資料庫查詢動作。
4. 針對磁碟讀寫速度的優化：除了葉子節點之外的其他節點只儲存鍵值，這樣對磁碟的單次讀寫可以獲取到儘可能多的資料。以MySQL為例，一個1000萬行的表對應的B+樹按照主鍵查詢理論上只需要3次磁碟IO，這相對於全表掃描帶來的磁碟IO是多個量級的效能提升。
5. MySQL等資料庫引擎在實際實現B+樹索引的時候，針對磁碟讀寫做了優化：非葉子節點中只存放key值，葉子節點中除了key值也會存放資料，按照存放資料的不同索引區分為主索引（聚簇索引）和輔助索引：
   a) 主索引的葉子節點中存放該key值對應的完整記錄，使用主索引進行查詢時，可以直接輸出記錄；一個表只能建立一個主索引。
   b) 普通索引的葉子節點則存放對應主鍵的值，因此在使用輔助索引進行查詢時，需要先查詢到主鍵值，然後再到主索引中進行查詢；一個表可以建立多個輔助索引。
6. 除了B+樹，關係型資料庫一般也支援雜湊索引，雜湊索引能夠非常高效地進行隨機查詢，但是對於範圍查詢、排序和分組都不支援。

9.資料庫事務是什麼？

資料庫事務是指一個邏輯單元執行的一系列操作，一個邏輯工作單元必須有四個屬性，稱為 ACID（原子性、一致性、隔離性和永續性）屬性
原子性（Atomicity）：事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部被執行，要麼都不執行。
一致性（Consistency）：事務應確保資料庫的狀態從一個一致狀態轉變為另一個一致狀態。一致狀態的含義是資料庫中的資料應滿足完整性約束。
隔離性（Isolation）：多個事務併發執行時，一個事務的執行不應影響其他事務的執行。
永續性（Durability）：已被提交的事務對資料庫的修改應該永久儲存在資料庫中

10.常見的OLAP多維資料分析包括

向上鑽取、向下鑽取、切片、切塊和旋轉等操作

11.關係型VS非關係型資料庫及其優缺點

1.常見的關係型資料庫包括SQLite、Oracle、mysql，
（1）它們的特點是：
1、關係型資料庫是指採用了關係模型來組織資料的資料庫；
2、 事務的一致性是關係型資料庫的最大特點；
3、關係模型指的就是二維表格模型，而一個關係型資料庫就是由二維表及其之間的聯絡所組成的一個數據組織。
（2）其優點如下：
1、便於理解：二維表結構的關係模型相對網狀、層次等其他模型來說更容易理解；
2、使用方便：使用SQL語言十分方便；
3、易於維護：大大減低了資料冗餘和資料不一致的概率；
（3）而缺點是讀寫效能比較差。
2.典型的NoSQL資料庫：臨時性鍵值儲存（memcached、Redis）、永久性鍵值儲存（ROMA、Redis）、面向文件的資料庫（MongoDB、CouchDB）、面向列的資料庫（Cassandra、HBase）
（1）非關係型資料庫的特點：
1、一般不支援ACID特性；
2、非關係型資料庫嚴格上不是一種資料庫，而是一種資料結構化儲存方法的集合。
（2）它的優點是：
1、相對於關係型資料庫，讀寫效能很高；
2、 資料沒有耦合性，容易擴充套件；
3、儲存資料的格式可以是多種的：nosql的儲存格式是key,value形式、文件形式、圖片形式等等，文件形式、圖片形式等等
（3）缺點在於不支援SQL，同時使用的成本也比較高。
注：耦合性也叫塊間聯絡。指軟體系統結構中各模組間相互聯絡緊密程度的一種度量。模組之間聯絡越緊密，其耦合性就越強，模組之間越獨立則越差，模組間耦合的高低取決於模組間介面的複雜性，呼叫的方式以及傳遞的資訊。

12.索引：B樹、B+樹區別

B樹：二叉樹，每個結點只儲存一個關鍵字，等於則命中，小於走左結點，大於走右結點；
B-樹：多路搜尋樹，每個結點儲存M/2到M個關鍵字，非葉子結點儲存指向關鍵字範圍的子結點；
所有關鍵字在整顆樹中出現，且只出現一次，非葉子結點可以命中；
B+樹：在B-樹基礎上，為葉子結點增加連結串列指標，所有關鍵字都在葉子結點中出現，非葉子結點作為葉子結點的索引；B+樹總是到葉子結點才命中；
B*樹：在B+樹基礎上，為非葉子結點也增加連結串列指標，將結點的最低利用率從1/2提高到2/3

區別:
b-樹，葉子節點跟非葉子節點都儲存資料
b+樹，只有在葉子節點儲存資料
B樹：有序陣列+平衡多叉樹；
B+樹：有序陣列連結串列+平衡多叉樹；
為啥索引使用 b+樹
資料庫索引採用B+樹的主要原因是B樹在提高了磁碟IO效能的同時並沒有解決元素遍歷的效率低下的問題。正是為了解決這個問題，B+樹應運而生。
B+樹只要遍歷葉子節點就可以實現整棵樹的遍歷。而且在資料庫中基於範圍的查詢是非常頻繁的，而B樹不支援這樣的操作（或者說效率太低）。
b+樹遍歷只需要遍歷葉子節點以及下一個葉子節點即可

13.資料庫檢視

檢視（子查詢）：是從一個或多個表匯出的虛擬的表，其內容由查詢定義。具有普通表的結構，但是不實現資料儲存。單表檢視一般用於查詢和修改，會改變基本表的資料；多表檢視一般用於查詢，不會改變基本表的資料。
1、檢視的作用
（1）簡化了操作，把經常使用的資料定義為檢視
  我們在使用查詢時，在很多時候我們要使用聚合函式，同時還要 顯示其它欄位的資訊，可能還會需要關聯到其它表，這時寫的語句可能會很長，如果這個動作頻繁發生的話，我們可以建立檢視，這以後，我們只需要select * from view就可以啦，這樣很方便。
（2）安全性，使用者只能查詢和修改能看到的資料
  因為檢視是虛擬的，物理上是不存在的，只是儲存了資料的集合，我們可以將基表中重要的欄位資訊，可以不通過檢視給使用者，檢視是動態的資料的集合，資料是隨著基表的更新而更新。同時，使用者對檢視不可以隨意的更改和刪除，可以保證資料的安全性。
（3）邏輯上的獨立性，遮蔽了真實表的結構帶來的影響
  檢視可以使應用程式和資料庫表在一定程度上獨立。如果沒有檢視，應用一定是建立在表上的。有了檢視之後，程式可以建立在檢視之上，從而程式與資料庫表被檢視分割開來。
2、檢視的缺點
（1）效能差
  資料庫必須把檢視查詢轉化成對基本表的查詢，如果這個檢視是由一個複雜的多表查詢所定義，那麼，即使是檢視的一個簡單查詢，資料庫也要把它變成一個複雜的結合體，需要花費一定的時間。
（2）修改限制
  當用戶試圖修改檢視的某些資訊時，資料庫必須把它轉化為對基本表的某些資訊的修改，對於簡單的檢視來說，這是很方便的，但是，對於比較複雜的試圖，可能是不可修改的。
  

14 .熱備份、冷備份

1.熱備份
是在資料庫執行的情況下，採用archivelog mode方式備份資料庫的方法。即熱備份是系統處於正常運轉狀態下的備份。
所以，如果你有一個冷備份而且又有熱備份檔案，在發生問題時，就可以利用這些資料恢復更多的資訊。熱備份要求資料庫在Archivelog()方式下操作，並需要大量的檔案空間。一旦資料庫執行在archivelog狀態下，就可以做備份了。
1.1 優點
1． 可在表空間或資料庫檔案級備份，備份的時間短。
2． 備份時資料庫仍可使用。
3． 可達到秒級恢復（恢復到某一時間點上）。
4． 可對幾乎所有資料庫實體做恢復
5． 恢復是快速的，在大多數情況下在資料庫仍工作時恢復。
1.2 不足
1． 不能出錯，否則後果嚴重
2． 若熱備份不成功，所得結果不可用於時間點的恢復
3． 因難於維護，所以要特別仔細小心，不允許“以失敗告終”。
2.冷備份
冷備份發生在資料庫已經正常關閉的情況下，當正常關閉時會提供給我們一個完整的資料庫。冷備份是將關鍵性檔案拷貝到另外的位置的一種說法。對於備份Oracle資訊而言**，冷備份是最快和最安全的方法**。
2.1 冷備份的優點是：
1、 是非常快速的備份方法（只需拷檔案）
2、 容易歸檔（簡單拷貝即可）
3、 容易恢復到某個時間點上（只需將檔案再拷貝回去）
4、 能與歸檔方法相結合，做資料庫“最佳狀態”的恢復。
5、 低度維護，高度安全。
不足
1、 單獨使用時，只能提供到**“某一時間點上”的恢復。**
2、 再實施備份的全過程中，資料庫必須要作備份而不能作其他工作。也就是說，在冷備份過程中，資料庫必須是關閉狀態。
3、 若磁碟空間有限，只能拷貝到磁帶等其他外部儲存裝置上，速度會很慢。
4、 不能按表或按使用者恢復。
如果可能的話（主要看效率），應將資訊備份到磁碟上，然後啟動資料庫（使使用者可以工作）並將備份的資訊拷貝到磁帶上（拷貝的同時，資料庫也可以工作）。
轉載自：https://baike.baidu.com/item/%E7%83%AD%E5%A4%87%E4%BB%BD/8862202#5

15.資料庫的完整性

1. 約束是用來確保資料的準確性和一致性。資料的完整性就是對資料的準確性和一致性的一種保證。
   資料完整性(Data Integrity)是指資料的精確(Accuracy)和可靠性(Reliability)。
2. 分為以下四類：

1. 實體完整性：規定表的每一行在表中是惟一的實體。
2. 域完整性：是指表中的列必須滿足某種特定的資料型別約束，其中約束又包括取值範圍、精度等規定。
3. 參照完整性：是指兩個表的主關鍵字和外關鍵字的資料應一致，保證了表之間的資料的一致性，防止了資料丟失或無意義的資料在資料庫中擴散。
4. 使用者定義的完整性：不同的關係資料庫系統根據其應用環境的不同，往往還需要一些特殊的約束條件。使用者定義的完整性即是針對某個特定關係資料庫的約束條件，它反映某一具體應用必須滿足的語義要求。

3. 完整性約束的型別
   可分為三種類型：與表有關的約束、域(Domain)約束、斷言(Assertion)

1. 與表有關的約束:是表中定義的一種約束。可在列定義時定義該約束，此時稱為列約束，也可以在表定義時定義約束，此時稱為表約束。
2. 域(Domain)約束：在域定義中被定義的一種約束，它與在特定域中定義的任何列都有關係。
3. 斷言(Assertion)：在斷言定義時定義的一種約束，它可以與一個或多個表進行關聯。