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