前面其實寫了好幾篇關於 mysql 索引的文章了，文章中有具體的例項和 sql 語句，這篇文章我想再用純大白話講講 mysql 索引，文中不涉及具體 sql 。
我之前甚至想過為啥要用資料庫來儲存資料，用普通的 txt 或者 word 這類檔案不行麼，這個問題其實可以從幾個方面來看，乙個是併發訪問資料加鎖，另乙個是資料安全性，再乙個是資料的查詢效能問題。這三個方面在 mysql 中都有對應的解決方案，比如事務、鎖、日誌系統(binlog、redolog 等)、索引。
為了實現高效查詢，就得找到一種合適的資料結構來儲存資料。首先我們可以想到使用雜湊表，雜湊錶能通過鍵值快速找到對應的值，但是因為雜湊是無序的，一般更適用於等值查詢，但實際業務中通過會有大量的區間查詢，比如查詢 id 在 1-100 間的值，使用雜湊的話效率就會大打折扣了。
那麼就要找到一種既能滿足等值查詢，又能滿足區間查詢的資料結構了，又會很容易想到陣列。陣列可以通過下標快速找到對應的值，因為陣列下標是有序的，所以通過遍歷下標就能很高效的完成區間查詢。
但是陣列也有乙個嚴重的問題，就是在刪除或者插入資料的時候可能會移動大量其他資料，這是乙個很大的效能消耗，所以陣列一般更適合儲存靜態資料，比如一些歷史資料，確定不會再更新的資料。
再乙個就是二叉搜尋樹了，二叉搜尋樹的查詢效率比較高，而且二叉搜尋樹的中序遍歷就是乙個有序陣列，但依然不能很好的支援區間查詢。
所以可以對二叉搜尋樹進行改造，樹的節點不再儲存具體資料，而是儲存索引值，資料儲存在最底層的葉子節點上，同時葉子節點間使用雙鏈表連線起來，這樣只需要先找到區間起始值的位置，然後往後遍歷到終止值，即可完成區間查詢。
另外說一點，mysql 中有乙個非常重要的模組，就是優化器，優化器的主要任務就是尋找一種更低代價方式去執行方式，通常會以掃瞄行數、是否需要排序、是否需要回表、是否需要臨時表等來作為代價依據。
所以通常同一條 sql 在不同資料量的情況下執**況可能會不一樣，或者明明為某些 where 字段建立了索引，查詢的時候偏偏又不走索引，這些情況其實都是經過優化器分析後作出的選擇。因此你要知道，一條 sql 最終該怎麼執行，還得看是在什麼樣的場景。
大白話解釋 氣泡排序
原理 乙個陣列裡，相鄰的兩個元素進行比較，兩兩比較。使用雙層for迴圈，外層迴圈代表比較的輪數 陣列元素個數 1 內層迴圈代表每輪比較多少次 陣列元素個數 1 public class bubblesort for int i 0 ia j 1 system.out.println arrays.t...
大白話說 async await ，面試專用
async await 將非同步寫成同步的樣子，並保證執行順序，解決 地獄的問題 如果你是寫成 地獄的樣式，乙個請求成功以後，在 裡面巢狀下乙個 這樣多級巢狀的 函式弊端很多，不直觀，強耦合性，的不確定性，不利於維護和復用 async await就解決了這個問題 最下方有案例參考 1 async的作...
快速排序（大白話）
假設我們現在對 6 1 2 7 9 3 4 5 10 8 這個10個數進行排序。首先在這個序列中隨便找乙個數作為基準數 不要被這個名詞嚇到了，就是乙個用來參照的數，待會你就知道它用來做啥的了 為了方便，就讓第乙個數6作為基準數吧。接下來，需要將這個序列中所有比基準數大的數放在6的右邊，比基準數小的數...