資料庫設計規範參考

1、關於表型別

表型別盡是用innodb，少用myisam

在讀取上innodb與myisam差不了多少，但在update上，myisam很吃虧

innodb 為行級鎖，支援事務，myisam為表級鎖，有時候會給表帶來不可預知的破壞

2、關於索引

索引可以加快我們sql查詢的效率，但並不是索引越多越好。索引越多，資料庫在寫入時就會越慢。

中文字串不推薦加索引，如果該字串使用比較頻繁，可以加一些輔助的字段來加索引，加快索引速度。例如：目前商家中心的主旺旺查詢比較多，增加了乙個欄位存crc32(主旺旺)並對此欄位加索引，查詢時使用主旺旺+crc32(主旺旺)的聯合條件查詢，加快查詢速度

多列索引有乙個優點最左字首，就是如果建立乙個有firstname、lastname、age列上的多列索引，就相當於建立了

* firstname，lastname，age

* firstname，lastname

* firstname

這三中相關的查詢都能用到這個過引，但這種多列索引也不能使用太多，請參照第一條。

3、關於分表

在設計表的初期就要做乙個評估，預估一下表的資料量有多大，能否承載2-3年的資料量。10個字段以內、讀寫不是很頻繁、欄位以數字為主的表。在1000萬到2000萬時，查詢還是很快的。但一般的表在500w到1000w就可以考慮分表。

一般分表的方式有，id取模、按時間段分表（如按天、按月、按年分表）、按量分表（如500萬一張表）

分表有好處，也會帶來一些問題，如翻頁問題、top問題

4、關於事務

當在同乙個操作中操作多個表時，可以使用事務，如：只有當a表寫成功的時候才可以寫b表，當b表寫失敗了，則回滾a表。

事務能很好的保證此動作的完整性，但大量使用事務，對資料庫的開銷也會很大，特別是在高併發的情況下。

一般事務使用在商業應用中以及一些對資料安全要求很高的應用。目前我們的專案中只有資金和報名使用了事務。

5、關於表的設計

注意表的可擴充套件性，具體可參考分表以及其它，比較你在設計一張支付寶相關的表時，可以考慮一下相容財付通、銀聯等其它相關。

注意表字段的冗餘，冗餘字段可能在維護時比較麻煩，但在後期複雜的業務當中，可能會節省很多的查詢開銷，所以在條件允許的情況下，盡量多冗餘幾個字段。

單個欄位的設計時，一定要注意字段型別、字段長度。字段型別的型別能節省儲存空間、優化查詢。

字段長度能一定要預估好，舉乙個例子：商家中心有一段時間，突然發現好幾個商家怎麼也無法入駐商家中心，**也沒有動過，找了好久，最後發現，家中心中的一線表裡面uid的長充是8位，需使用者中心的uid是11位。而該商家的uid正好超過8位，所以無法寫入到商家中心的表中。

表字段盡量給預設值，不要給null。