最近要換工作了。換工作前，依然還沒有學完/學通公司的資深工程師 Mike 的 skills。只好先把他以前寫在 slack 的 comments 拷貝出來。
==================================================
1. 一張 table 的資料，一定只有一個順序存在「硬碟」中
2. Clustered Index，是一個用資料規則來決定資料在「硬碟中」的順序的方法
3. 當需要進行範圍查詢時，Clustered Index 可以利用到「硬碟」的循序存取效能
4. 不是有索引，資料庫的查詢最佳化就會使用，當資料量不多時，資料庫會直接使用 Full table scan
5. 就點查詢而言，WHERE 的條件在 Clustered Index 比 Secondary Index 還快，因為 Leaf Node 就是 Data Block
6. 資料庫效能是在「新增、修改、刪除」與「查詢」之間取捨 --- 註：前同事 Mike 對 relational database 的理解沒有錯。然而，在 Martin Kleppmann 的 Turning the database inside out with Apache Samza 這個 talk 裡，他探討了一種 system architecture，透過 event sourcing 與 CQRS ，可以達成不需要為了 Read 或是 Write 的效能而做出 trade-off。
7. Secondary Index Leaf 是 Clustered Index Key 是 MySql InnoDB 特有的實作方式
8. MySql 選擇了讓 Secondary Index 「新增、修改、刪除」容易，但查詢付出代價
9. MySql 是查詢最佳化很蠢的資料庫，意思要用很多索引，所以 InnoDB 實作 Secondary Index Leaf 到 Value of PK，在多個索引的情況下，PK 的順序不影響 2nd Index 的 Leaf Node 的值
10. 在那一篇引起戰文的為何用 MySql 取代 PostgreSql 的文章(UBer)中，關於索引的部份，他們在不斷更新資料的前提下，再加上有一堆索引，所以使用 MySql，更新的成本比 PostgreSql 低
11. 在 MVCC 的比較上，當 Transaction Log 與 Data Block 放同一個磁碟子系統時，
假設 Read(50%) 與 Write(50%)，PostgreSql 可能比 MySql 好太多，因為減少了大量的 Random Access
=============
資料庫先求正確，再求效能，不正確的資料會拖累效能，甚至無法 Tuning，因為隨著時間，相依的程式碼太多。
資料庫資料的修正與程式的 Patch 不是同樣成本的事，讓資料嚴謹至少佔了系統品質的 60%。程式出錯，還有資料庫把關。
資料庫嚴謹的代價是效能，但它是可調效的，資料出錯，通常是前端先發現，然後要一層層檢查是哪裡出錯，是查詢有錯、還是新增修改有錯、還是前端有錯。甚至可能只有正式機才會有資料範例，此時就可能要在正式機上除錯。
==============
資料庫有兩本書就用了
The Art of SQL
Database: Principles, Programming, and Performance
