《高性能MySQL》讀書筆記
《High Performance MySQL》真是本經典好書，從應用層到數據庫到硬件平台，各種調優技巧、常見問題全都有所提及。數據庫的各種概念技巧平時都有接觸，像索引、分區、Sharding等等，但要想真正提高還是得如此系統學習一下。
Chapter 1: MySQL Architecture and History
1.1 Transaction Isolation Level
1.2 Implicit and Explicit Locking
使得事務具有較高的並發度，因為解鎖不必發生在事務結尾。它的
不足是沒有解決死鎖的問題，因為它在加鎖階段沒有順序要求。如兩個事務分別申請了A, B鎖，接著又申請對方的鎖，此時進入死鎖狀態。
1.3 Multiversion Concurrency Control
Innodb只是借了MVCC這個名字，提供了讀的非阻塞而已。
Chapter 4: Optimizing Schema and Data Types
4.1 Choosing Optimal Data Types
Smaller is usually better(越小通常越好)：因為占用更少磁盤空間，內存以及CPU緩存，所以越小通常代表越快。
Simple is good(簡單的就是好的)：因為字符集和排序規則(Collation)使得字符串的比較很復雜，所以我們應當用Integer等內建類型而非字符串來保存日期時間或IP地址。
Avoid NULL if possible(盡可能避免NULL)：MySQL對NULL有特殊的處理邏輯，所以NULL會使索引、索引統計、值比較都變得更加復雜。
4.2 Using ENUM Instead Of A String Type
4.3 Cons of A Normalized Schema
JOIN使我們無法通過一個索引就同時完成排序和過濾。改為非規范化 => SELECT .. FROM user_message WHERE account_type = 'premium' ORDER BY published DESC LIMIT 10則(account_type, published)上的索引能高效地完成任務！
這幾種技術本質上都是為了加速查詢操作，但代價是拖慢了寫操作，並且會增加開發的復雜度。
4.5 Materialized Views
4.6 Counter Tables
ps：如果需要每天刷新計數器的話，那麼建表時就加入時間列：CREATE TABLE daily_hit_counter( day date not null, slot tinyint unsigned not null primary key, cnt int unsigned not null, primary key(day, slot)) ENGINE=InnoDB;
pss：如果不想每天都插入初始數據的話，可以用下面的SQL：mysql> INSERT INTO daily_hit_counter(day, slot, cnt) VALUES(CURRENT_DATE, RAND() * 100, 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1;
psss：如果想減少計數器的行數來節約空間，那麼可以執行一個定期任務來合並所有記錄到Slot 0：
5.1 B-Tree Family
各種變形的核心是圍繞著內結點出度(例如基於內存的T樹和基於磁盤的B樹)、存儲使用率(B樹和B+樹)等方面進行的。
3次磁盤IO操作和3次內存查找操作。關於內存中的文件名查找，由於是一個有序表結構，可以利用折半查找提高效率。至於IO操作是影響整個B樹查找效率的決定因素。當然，如果我們使用平衡二叉樹的磁盤存儲結構來進行查找，磁盤4次，最多5次，而且文件越多，B樹比平衡二叉樹所用的磁盤IO操作次數將越少，效率也越高。
