轉自：?https://book.douban.com/review/8122660/

?

版權歸作者所有，任何形式轉載請聯(lián)系作者。
作者：姚澤源（來自豆瓣）
來源：https://book.douban.com/review/8122660/

在知乎上發(fā)過一次，這里也發(fā)一遍吧

--------正文開始--------

草草翻完了《高性能MySQL》，印象最深的地方就是：這確實不適合初學者去看。

花了三個月的時間慢慢看完了這本，看的一頭霧水。第一章概論講了不少新奇的概念，比如隔離級別，比如多版本并發(fā)控制(MVVC)。但是從第二章起，所講的內容基本就和日常應用沒什么太大關系了。如果要簡單概括一下的話就是

1. 儲存引擎務必使用InnoDB

2. 創(chuàng)建新數(shù)據(jù)庫時要用最新的MySQL版本(當然是GA版)

3. 輕易不要升級MySQL

然后就沒了。對于其他的內容，不管是服務器性能優(yōu)化還是MySQL主從備份，這些其實都和一名普通的技術人員沒有關系。相較于書中提到的通過修改frm文件實現(xiàn)快速新增列這種神奇方法，技術人員最好的做法還是：盡可能的避免使用alter語句或者說在項目一開始時就要想好數(shù)據(jù)表的用途。如果你是想改進自己的SQL水平的話，那應該去看 SQL快速優(yōu)化300例 ,至少，不是這本書。

寫一下收獲吧(SQL相關，不僅僅是MySQL)，畢竟翻完了不是。

1. 盡量避免在線上使用alter

在使用alter新增列時,會引發(fā)一個全表鎖，數(shù)據(jù)庫會暫停響應直到新列添加完成(在已有數(shù)據(jù)中添加新列,在數(shù)據(jù)庫表結構中添加列定義)。鎖定的時間隨表內數(shù)據(jù)量的大小線性增長。如果是在線上環(huán)境的話，即使很短的時間，也夠阻塞不少請求了←_←

2. 可以通過冗余數(shù)據(jù)來提升SQL查詢的性能

在標準的數(shù)據(jù)庫教科書中，數(shù)據(jù)表結構按說是要符合范式要求的(1NF~5NF)。比如，通過把用戶信息和訂單內容獨立開，這樣就可以設計出來沒有冗余數(shù)據(jù)的數(shù)據(jù)庫表結構——俗稱學院派數(shù)據(jù)庫表結構。但是，學院派依托的環(huán)境是銀行系統(tǒng)這樣的大型工程，查詢帶來的性能損耗遠小于冗余數(shù)據(jù)帶來的損耗。但在真實應用中，表里的數(shù)據(jù)很少能達到1000萬行以上的，在這時，大部分的性能全浪費在多次查詢上了。這時候，學院派的做法就不如直接在數(shù)據(jù)表中添加冗余數(shù)據(jù)(例如把用戶手機號和訂單一起存取),這樣在展示的時候一條SQL就可以搞定。

> 『PHP絕大部分的性能都浪費在和MySQL服務器通訊上了』

3. 使用tinyint或者varchar作為枚舉類型，而不是使用enum

理由很簡單: enum在新增類型的時候需要使用alter語句進行全表新增，線上數(shù)據(jù)庫時不時的來上一回全表鎖誰受的了。。。

一般來說，使用 tinyint + 代碼中利用常量進行定義 是最好的方案，如果要增強可讀性的話可以使用varchar, 因為常量一共也不超過10個字母，從性能上來說varchar也可以接受

4. 可視化工具

客戶端的話個人建議使用adminer,有ngnix之后配上一個index.php文件就能用。非要使用客戶端的話用MySQL Workbench也可以，MySQL自己出的。這兩個都在《高性能MySQL》的推薦之列，可以考慮

5. 使用調試語句查看性能

常用的調試語句如EXPLAIN, SHOW這種，現(xiàn)用現(xiàn)查即可

6. 索引數(shù)據(jù)一般都在內存里

結論:排序時直接使用索引排序是最快的,索引不要太多，太多之后跟把整個表放內存里就等效了(還不如使用Redis)

補充:排序時EXPLAIN發(fā)現(xiàn)不是index,而是filesort也不用太擔心，因為只有這兩種狀態(tài)，不是index就是filesort，性能只要不是太坑直接上就行

7. 分表分庫，歷史數(shù)據(jù)獨立建表

MySQL處理1000萬行以下的數(shù)據(jù)時性能是非常好的——那1000萬行以上時怎么辦呢？

直接分表啊。

比如，可以按時間分，自增id在500萬之前的，獨立分到一個表里，在程序代碼里寫死，用到的時候再去讀

或者，按一個數(shù)取模，根據(jù)余數(shù)選擇對應的表。

8. 對于重要數(shù)據(jù)，一定要開啟二進制日志

手滑刪過全表的同學都懂。。。

然后，解釋下兩個概念：

1. 隔離級別

每執(zhí)行一次SQL稱為一件事務，如果事務所涉及到的內容在事務進行中發(fā)生了改變，對應于事務所能讀取到的實際內容，就產生了四種標準情況，這四種標準情況被稱為四種隔離級別(僅就MySQL而言，對于其他數(shù)據(jù)庫實現(xiàn)可能會有不同的區(qū)分標準)

1. READ UNCOMMIT(未提交讀)

在READ UNCOMMIT級別中，即使沒有提交，每個事務的操作對于其他事務也都是可見的。在這種情況下，事務可以讀取未提交的數(shù)據(jù)，又稱臟讀(DIRTY READ)。從性能上來說，臟讀并不比其他模式優(yōu)秀多少，但是會引發(fā)各種嚴重的問題(比如說銀行存款數(shù)據(jù)寫入到一半來了一個讀操作。。。)。一般情況下，不建議使用

2. READ COMMIT(未提交讀)

大部分數(shù)據(jù)庫系統(tǒng)默認的隔離級別都是READ COMMIT(但MySQL不是)。在READ COMMIT這一級別中，事務所修改的數(shù)據(jù)只有提交了之后才會被其他事務讀取到。換句話說，一個事物從開始之后到結束之前，所做的任何修改對其他事物都是不可見的。這個級別實際上已經(jīng)比較符合我們讀取數(shù)據(jù)的預期了。但是，如果執(zhí)行兩次同樣的查詢，可能會出現(xiàn)兩遍結果不一致的情況(查詢執(zhí)行過程中有其他事務提交完成),所以，這一級別又叫不可重復讀(nonrepeatable read)

3. REPEATABLE READ(可重復讀)

REPEATABLE READ解決了臟讀的問題，同時也是MySQL的默認事務隔離級別。這一級別保證了在同一個事務中多次讀取同樣的記錄結果是一致的。但是理論上，可重復讀還是沒法解決幻讀(Phantom Read)的問題。幻讀是指：在某個事務讀取某個范圍內的的記錄時(id>1 && id < 100),另外一個事物又再該范圍內插入了新紀錄，當之前的事務再次讀取該范圍的記錄時，就會產生幻行(Phantom Row)。不過InnoDB通過多版本并發(fā)控制(MVVC, Multiversion Concurrency Control)解決了這個問題

4. SERIALIZABLE(可串行話)

SERIALIZABLE是最高的隔離級別。它通過強制讓事務串行執(zhí)行，可以避免前面所說的全部問題。本質上說，SERIALIZABLE會在讀取的每一行數(shù)據(jù)上都加上鎖, 對性能影響非常嚴重。只有在非常需要確保數(shù)據(jù)一致性，且可以接受沒有并發(fā)的情況下，才可以考慮使用此級別

2. 多版本并發(fā)控制

這是個很玄乎的詞，但說白了就是：通過保存數(shù)據(jù)在某個時間點的快照，來確保對于不同開始時間的事務，他們對于同一張表，在同一時刻看到的數(shù)據(jù)都是一樣的。

對于InnoDB來說就是：通過在每行記錄后邊保存兩個隱藏列，一列記錄創(chuàng)建時間，一列記錄過期時間（實際上存儲的是系統(tǒng)版本號）,每開始一個事務，系統(tǒng)版本號都會自動遞增。在事務開始時刻的系統(tǒng)版本號就會作為事務的版本號，用來作為數(shù)據(jù)庫查詢的依據(jù)，以此實現(xiàn)：多版本并發(fā)控制

大致就這些。看起來很高大上的一本書，實際上看了跟沒看差不多(DBA除外)。不推薦閱讀/購買

?

（但我對高性能mysql的印象蠻好的，推薦閱讀。）

?

總結

以上是生活随笔為你收集整理的转-《高性能mysql》并不是一本好书——SQL笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。