題記：主要記錄同學分享的關于數據庫設計方面的內容，思考過一點，記錄下來。
一、從需求開始，考慮數據庫的設計，且結合具體數據庫特性
一個論壇，要求顯示帖子的總條數，對于mysql、innodb引擎；上線前期完全沒有問題，當人氣積累，帖子達到千萬級別時，此時性能的問題就會顯現出來。好的設計，是需求階段就要考慮的。對于我，這是一個思想概念上的轉變。
但引擎如果換成myisam，就算數據達到億的級別，“統計總數”這樣的問題還會存在嗎 ？不會，myisam自身就會維護總數信息。因此設計，必須結合具體的數據庫的特性來做，不能以一概全。
二、應該遵循原則 （未驗證）
1.小結果集驅動大結果集。理由：mysql的連接查詢原理 ？
2.盡可能在索引中完成排序。理由：索引本身就是有序的
3.只取自己需要的column ？
4.避免復雜的連接查詢和子查詢。
5.適當的數據冗余.理由：帖子表&用戶表，如果帖子表擁有username，則每次帖子的顯示是不需要連接查詢獲取username。
6.應用層的cahce機制 ？
三、概念
1.垂直拆分：按列進行分割，即把一條記錄分開多個地方保存，每個子表的行數相同。帖子表，id、userid、username、content、xxx ...前面4個字段很常用，但是后面xxx等很多字段，不常用，數據量很大。進行垂直拆分，table1字段包含“id、userid、username、content”,table2包含“xxx、...”等不常用字段。優點：減少io的操作。缺點：如果需要不常用字段信息，需要連表查詢。
2.水平拆分：按記錄進分分割，不同的記錄分開保存，每個子表的列數相同。比如：淘寶的用戶交易數據，根據用戶id取模，確定具體的數據存放在那個數據庫。水平拆分會給應用帶來復雜性。
3.集群：提高系統的可用性。分庫的節點引入多臺機器，每臺機器保 存的數據是一樣，負載均衡在多臺機器。如何均衡、探測機器的可用性，是新的問題 ？
4.主備：一般的互聯網應用中，經過一些數據調查得出結論，讀/寫的比例大概在 10：1左右。為什么要讀寫分離：寫操作涉及到鎖的問題，不管是行鎖還是表鎖還是塊鎖，在大并發的情況下，效率很低。寫操作集中在一個節點上，而讀操作其其他 的N個節點上進行。讀寫分離引入的新問題：比如我的Master上的數據怎樣和集群中其它Slave機器保持數據的同步和一致呢?