工作中我們經常查詢資料庫,用乙個查詢,得到想要的資料。可有想過,我們得到答案經過了哪些磨難？經歷了哪些**？
本節將以乙個sql的執行過程來了解 mysql 整體架構，對mysql有乙個全面，清晰的認知，for造航母。
第一關: 聯結器,客戶端傳送一條查詢給伺服器,包含客戶端相關資訊(ip,使用者,密碼);伺服器完成驗證（報告太君,自己人,可以放行）。
第二關: 查詢快取,執行查詢語句的時候,會先查詢快取,我們會發現某個查詢，查詢第二次的時候非常快便是這個原因(mysql8.0 廢除這個功能,太雞肋)。
第三關: 解析器,第一步解析你的語法（單詞別寫錯了，寫錯了我可不會幹活），主要是關鍵字；第二步解析涉及到的物件是否存在，人都沒有，跟個空氣聊啥呢；第三步，涉及到的物件使用者是否有對應的許可權（哎呀，不給錢就不給摸，不給摸）。
第四關: 優化器,當語法與語義都沒有問題許可權也匹配，此時資料庫便開始真正為你服務了，根據一定得演算法規則，對你的查詢進行優化，尋找最優的執行計畫（這就跟找老婆一樣，國家分配的跟自己找的肯定還是不一樣的，多數情況下，還是自己找的好）。
第五關: 執行器，先判斷資料是否在緩衝池中，若在，直接返回，若不在，則先從磁碟檔案中載入到記憶體（反正今天要定了）。
第六關：資料返回，資料返回是一邊查詢，一邊返回，並不是一次返回，雖然看上去是一下突然返回的（這就好像『學外語』，你看見的不一定就是真的）。
旅行圖如下
最外層客戶端：各種語言api連線資料庫
第一層：連線層，包含連線池，身份驗證，查詢快取
第二層：核心服務層，解析器，優化器，跨儲存引擎的函式，儲存過程，觸發器，檢視，sql介面，管理服務工具元件
第三層：儲存引擎層，不同儲存引擎即資料的訪問方式不同
第四層：檔案系統，底層儲存資料的磁碟
innodb 儲存引擎3大特性
自適應hash索引
b+樹的高度一般為3~4層,故需要3~4次的查詢，如果觀察到建立雜湊索引可以帶來速度提公升,則建立雜湊索引,稱之為自適應雜湊索引(adaptive hash index,ahi) ahi是通過緩衝池的b+樹頁構造而來,因此建立的速度很快,而且不需要對整張表構建雜湊索引。 innodb儲存引擎會自動根據訪問的頻率和模式來自動地為某些熱點頁建立雜湊索引 --來自innodb 技術內幕（人工智慧趕腳有沒有）
缺點: 跟普通索引一樣需要額外開銷維護。
插入緩衝
對於非聚集類索引的插入和更新操作，不是每一次都直接插入到索引頁中，而是先插入到記憶體中。具體做法是：如果該索引頁在緩衝池中，直接插入；否則，先將其放入插入緩衝區中，再以一定的頻率和索引頁合併，這時，就可以將同乙個索引頁中的多個插入合併到乙個io操作中，大大提高寫效能。（一定是非聚集索引）
缺點：可能導致資料庫宕機後例項恢復時間變長，占用太多緩衝池記憶體雙寫
當mysql將髒資料flush到data file的時候, 先使用memcopy 將髒資料複製到記憶體中的double write buffer ，通過double write buffer再分2次，每次寫入1mb到共享表空間，然後馬上呼叫fsync函式，同步到磁碟上，避免緩衝帶來的問題。（前倆個是提公升效能，雙寫主要保證資料頁的可用性）
ASP Access莫名奇妙的sql語句錯誤解決
有時候寫asp用conn.execute sql 查詢 更新 插入access資料庫資料時，明明正確的語句卻往往會顯示sql語句錯誤，相當惱火，特進行了歸納，可適當為字段新增 解決 例 select from a 如出現錯誤，可改為 select from a 例 update user set p...
ASP Access莫名奇妙的sql語句錯誤解決
有時候寫asp用conn.execute sql 查詢 更新 插入access資料庫資料時，明明正確的語句卻往往會顯示sql語句錯誤，相當惱火，特進行了歸納，可適當為字段新增 解決 例 select from a 如出現錯誤，可改為 select from a 例 update user set p...
最短的旅程
在byteland有n個城市 編號從1到n 它們之間通過雙向的道路相連。byteland的國王並不大方，所以，那裡只有n 1條道路，但是，它們的連線方式使得從任意城市都可以走到其他的任何城市。一天，starhder到了編號為k的城市。他計畫從城市k開始，遊遍城市m1，m2，m3，mj 不一定要按這個...