高性能MySQL（第4版）

分表如何設計主鍵問題 因爲當一個葉子節點存滿後，此時又新增一個新的值，也要插入到這個節點中，那麼該節點中的最後一個數據只能往後面的節點移動，而後面的節點又需要繼續往後面移動，最終才能給新增的值騰出位置 因爲這個過程索引樹的結構正在發生變更，所以會加鎖防止其他事務讀到不對的數據，而挪動數據、加鎖阻塞都需要時間，因此樹分裂會導致索引性能下降 但如果選擇按需遞增的字段就不會有這個問題，畢竟每次新增的值，都會直接放入到最後面去插入，並不會導致樹結構發生分裂 主鍵生成的常見思路：UUID、數據庫自增和雪花算法 UUID 的弊端有兩個 過長 UUID 不是遞增的 引發頁分裂，頁分裂還會造成一個問題，就是邏輯上相鄰的兩個頁，在真實存儲的磁盤上，它們可能離得很遠，這樣就無法利用局部性原理 無法利用順序讀特性 自增主鍵其實還有一個好處，就是數據會有更大的概率按照主鍵的大小排序，兩條主鍵相近的記錄，在磁盤上位置也是相近的，那麼可以預計，在範圍查詢的時候，我們能夠充分利用到磁盤的順序讀特性 數據庫步長自增 舉個例子，經過分庫分表之後我有十個表，那麼我可以讓每個表按照步長來生成自增 ID。比如說第一個表就是生成 1、11、21、31 這種 ID，第二個表就是生成 2、12、22、32 這種 ID 這種方案非常簡單，而且我們本身在應用層並不需要做任何事情，只是需要在創建表的時候指定好步長就可以了。ID 雖然不是全局遞增的，但是在一個表內部，他肯定是遞增的，這個方案的性能取決於數據庫的性能，應用層上面也不需要關注 雪花算法 雪花算法保證 ID 唯一性的理由也很充分了 時間戳是遞增的，不同時刻產生的 ID 肯定是不同的 機器 ID 是不同的，同一時刻不同機器的 ID 肯定是不同的 同一時刻同一機器上，可以輕易控制序列號 雪花算法採用 64 位來表示一個 ID，其中 1 比特保留，41 比特表示時間戳，10 比特作爲機器 ID，12 比特作爲序列號 調整分段： 大多數情況下，如果自己設計一個類似的算法，那麼每個字段的含義、長度都是可以靈活控制的。比如說時間戳 41 比特可以改的更短或者更長，比如說 39 比特也能表示十幾年，其實也夠用 機器 ID 雖然明面上是機器 ID，但是實際上並不是指物理機器，準確說是算法實例。例如，一臺機器部署兩個進程，每個進程的 ID 是不同的；又或者進一步切割，機器 ID 前半部分表示機器，後半部分可以表示這個機器上用於產生 ID 的進程、線程或者協程。甚至機器 ID 也並不一定非得表示機器，也可以引入一些特定的業務含義。而序列號也是可以考慮加長或者縮短的 雪花算法可以算是一種思想，藉助時間戳和分段，我們可以自由切割 ID 的不同比特位，賦予其不同的含義，靈活設計自己的 ID 算法 序列號耗盡 但是這裏還有一個問題，就是不管你怎麼設計雪花算法，你的序列號長度都有可能不夠。比如說前面標準的是 12 比特，那麼有沒有可能併發非常高，以至於 12 比特在某一個特定的時刻機器上的比特全都用完了呢 一般來說可以考慮加長序列號的長度，比如說縮減時間戳，然後挪給序列號 ID。當然也可以更加簡單粗暴地將 64 位的 ID 改成 96 位的 ID，那麼序列號 ID 就可以有三四十位，即便是國際大廠也不可能用完了。不過，徹底的兜底方案還是要有的。我們可以考慮引入類似限流的做法，在當前時刻的 ID 已經耗盡之後，可以讓業務方等一下。我們的時間戳一般都是毫秒數，那麼業務方最多就會等一毫秒 業務方等待算是一個比較危險的方案，因爲這可能導致大量業務方阻塞住，導致線程耗盡或者協程耗盡之類的問題。不過如果是偶發性的序列號不夠，那麼問題不大，因爲阻塞的業務方很快就能拿到 ID 那麼如果序列號耗盡不是一個偶發性的問題，是長期的問題，那麼還是要考慮從業務角度切割，不同業務使用不同的 ID 生成，就不要共享了。又或者，逼不得已還是用 96 或者128 位的，一了百了 數據堆積 在低頻場景下，很容易出現序列號幾乎沒有增長，從而導致數據在經過分庫分表之後只落到某一張表裏面的情況。爲了解決這種問題，可以考慮這麼做，序列號部分不再是從 0 開始增長，而是從一個隨機數開始增長。還有一個策略就是序列號從上一時刻的序列號開始增長，但是如果上一時刻序列號已經很大了，那麼就可以退化爲從 0 開始增長。這樣的話要比隨機數更可控一點，並且性能也要更好一點 一般來說，這個問題只在利用 ID 進行哈希的分庫分表裏面有解決的意義。在利用 ID 進行範圍分庫分表的情況下，很顯然某一段時間內產生的 ID 都會落到同一張表裏面。不過這也是我們的使用範圍分庫分表預期的行爲，不需要解決。 主鍵內嵌分庫分表大多數時候，我們會面臨一個問題，就是分庫分表的鍵和主鍵並不是同一個。比如說在 C 端的訂單分庫分表，我們可以採用買家 ID 來進行分庫分表。但是一些業務場景，比如說查看訂單詳情，可能是根據主鍵又或者是根據訂單 SN 來查找的 那麼我們可以考慮借鑑雪花算法的設計，將主鍵生成策略和分庫分表鍵結合在一起，也就是說在主鍵內部嵌入分庫分表鍵。例如，我們可以這樣設計訂單 ID 的生成策略，在這裏我們假設分庫分表用的是買家 ID 的後四位。第一段依舊是採用時間戳，但是第二段我們就換成了這個買家後四位，第三段我們採用隨機數 普遍情況下，我們都是用買家 ID 來查詢對應的訂單信息。在別的場景下，比如說我們只有一個訂單 ID，這種時候我們可以取出訂單 ID 裏嵌入進去的買家 ID 後四位，來判斷數據存儲在哪個庫、哪個表。類似的設計還有答題記錄按照答題者 ID 來分庫分表，但是答題記錄 ID 本身可以嵌入這個答題者 ID 中用於分庫分表的部分 這一類解決方案，核心就是不拘泥於雪花算法每一段的含義。比如說第二段可以使用具備業務含義的 ID，第三段可以自增，也可以隨機。只要我們最終能夠保證 ID 生成是全局遞增的，並且是獨一無二的就可以

整體上寫得不錯，適合MySQL進階，標記下個人認爲值得學習/有所啓發的知識點： 1. Performance Schema的作用，啓停和原理； 2. 操作系統和硬件優化：RAID控制器爲何能提高寫操作I/O，事務系統採用write-ahead logging策略的原因，vmstat/dstat/collectl命令； 3. 優化服務器設置：最小化MySQL配置項，thread_cache_size/skip_name_resolve/innodb_old_blocks_time等配置的作用，推薦生產環境使用innodb_dedicated_server參數組； 4. 後臺開發人員重點關注：第六章schema設計與管理，第七章創建高性能索引，第八章查詢性能優化； 5. 複製：優先考慮基於行的複製（避免重放故障），優先啓用GTID特性執行主從備份，注意啓停super_read_only防止誤寫； 6. 備份與恢復：物理備份工具（Percona XtraBackup），邏輯備份首選（mydumper/myloader），優先考慮物理備份； 7. 擴展MySQL：Vitess，ProxySQL； 8. 推薦補充讀物：《SRE: Google運維解密》，《Google SRE工作手冊》，《性能之巔：系統、企業與雲可觀測性》； 當然，也存在不足/待補充的地方，比如，缺少MySQL鎖機制，事務二階段提交，MVCC原理等知識點的講解。

從23年開始讀的這本書，到26年讀完。大約過了2年半（警覺） 開始只看了索引以及查詢優化。其他的章節都沒看懂。所以並不適合新手看。（嗯？如何定義新手呢？） 不過這本書開啓了我的mysql優化啓蒙之路。

大體上還是推薦閱讀，特別是相對於第三版本書更新了很多新版本的內容以及涉及到雲和雲原生相關的知識。有幾點不好的地方，一是有些地方翻譯的很生硬，二是翻到最後都沒有看到參考鏈接在哪裏可以看到，我從原文補充到評論裏不少

寫的不好，知識點總是斷斷續續，很不專業，讀起來也很晦澀

剛出版就上架了？不得不說，微信讀書有點東西。。。《高性能MySQL》第四版相對於第三版在減少內容的同時竟然保存了所有精華，實在令人感動，本書深入淺出、詳略得當，每一句話都值得細細品讀，配合官方文檔學習效果更棒！數據庫基礎的學習，看這本書結合官方文檔，對於大多數DBA已足夠，對於開發者應付日常工作完全綽綽有餘。

翻譯過來的，感覺有的地方翻譯的不到位。而且感覺這本書對開發的幫助不是特別大，或許對運維/DBA有幫助吧，像MVCC、ACID、鎖等等講的不是特別深入。新手小白，或者只工作幾年的同學來講，還是可以讀一讀的。

非常棒的MySQL學習書籍，雖然說現在pgsql佔用率越來越高，但是現在仍然有很多的項目使用MySQL，這本書非常適合進階，沒想到第四版這麼快就出來了，基於MySQL8.0的，項目中有數據庫需求的可以讀一下

翻譯真差勁，讀起來很拗口，還不如不翻譯誤人子弟

書裏提到的面很寬，比較着重於性能檢測方面。另外感覺作者像是 Percona 的佈道者似的，從頭到尾都在宣傳這個軟件。