19條規則摘要如下：
規則1：一般情況可以選擇myisam儲存引擎，如果需要事務支援必須使用innodb儲存引擎。
規則2：命名規則。
規則3：資料庫字段型別定義
經常需要計算和排序等消耗cpu的字段,應該盡量選擇更為迅速的字段，如用timestamp(4個位元組，最小值1970-01-01 00:00:00)代替datetime（8個位元組，最小值1001-01-01 00:00:00）,通過整型替代浮點型和字元型
變長字段使用varchar，不要使用char
對於二進位制多**資料，流水佇列資料(如日誌)，超大文字資料不要放在資料庫欄位中
規則4：業務邏輯執行過程必須讀到的表中必須要有初始的值。避免業務讀出為負或無窮大的值導致程式失敗
規則5：並不需要一定遵守正規化理論，適度的冗餘，讓query儘量減少join
規則6：訪問頻率較低的大字段拆分出資料表。有些大字段占用空間多，訪問頻率較其他字段明顯要少很多，這種情況進行拆分，頻繁的查詢中就不需要讀取大字段，造成io資源的浪費。
規則7：大表可以考慮水平拆分。大表影響查詢效率，根據業務特性有很多拆分方式，像根據時間遞增的資料，可以根據時間來分。以id劃分的資料，可根據id%資料庫個數的方式來拆分。
規則8：業務需要的相關索引是根據實際的設計所構造sql語句的where條件來確定的，業務不需要的不要建索引，不允許在聯合索引（或主鍵）中存在多於的字段。特別是該字段根本不會在條件語句中出現。
規則9：唯一確定一條記錄的乙個欄位或多個欄位要建立主鍵或者唯一索引，不能唯一確定一條記錄，為了提高查詢效率建普通索引
規則10：業務使用的表，有些記錄數很少，甚至只有一條記錄，為了約束的需要，也要建立索引或者設定主鍵。
規則11：對於取值不能重複，經常作為查詢條件的字段，應該建唯一索引(主鍵預設唯一索引)，並且將查詢條件中該字段的條件置於第乙個位置。沒有必要再建立與該字段有關的聯合索引。
規則12：對於經常查詢的字段，其值不唯一，也應該考慮建立普通索引，查詢語句中該字段條件置於第乙個位置，對聯合索引處理的方法同樣。
規則13：業務通過不唯一索引訪問資料時，需要考慮通過該索引值返回的記錄稠密度，原則上可能的稠密度最大不能高於0.2，如果稠密度太大，則不合適建立索引了。
規則14：需要聯合索引(或聯合主鍵)的資料庫要注意索引的順序。sql語句中的匹配條件也要跟索引的順序保持一致。
注意：索引的順勢不正確也可能導致嚴重的後果。
規則15：表中的多個字段查詢作為查詢條件，不含有其他索引，並且字段聯合值不重複，可以在這多個欄位上建唯一的聯合索引，假設索引欄位為 (a1,a2,...an),則查詢條件(a1 op val1,a2 op val2,...am op valm)m<=n,可以用到索引，查詢條件中字段的位置與索引中的字段位置是一致的。
規則16：聯合索引的建立原則(以下均假設在資料庫表的字段a,b,c上建立聯合索引(a,b,c))
規則17：重要業務訪問資料表時。但不能通過索引訪問資料時，應該確保順序訪問的記錄數目是有限的，原則上不得多於10.
規則18：合理構造query語句
規則19：應用系統的優化
1.優化你的sql和索引；
2.加快取，memcached,redis；
3.做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
4.mysql自帶分割槽表，先試試這個，對你的應用是透明的，無需更改**,但是sql語句是需要針對分割槽表做優化的，sql條件中要帶上分割槽條件的列，從而使查詢定位到少量的分割槽上，否則就會掃瞄全部分割槽，另外分割槽表還有一些坑，在這裡就不多說了；
5.做垂直拆分，其實就是根據你模組的耦合度，將乙個大的系統分為多個小的系統，也就是分布式系統；
6.水平切分，針對資料量大的表，這一步最麻煩，最能考驗技術水平，要選擇乙個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將資料定位到限定的表上去查，而不是掃瞄全部的表；
7、選取最適用的字段屬性
8、使用連線（join）來代替子查詢(sub-queries)
9、使用聯合(union)來代替手動建立的臨時表
10、事務
11、鎖定表
如何設計或優化千萬級別的大表？此外無其他資訊，個人覺得這個話題有點範，就只好簡單說下該如何做，對於乙個儲存設計，必須考慮業務特點，收集的資訊如下：
1.資料的容量：1-3年內會大概多少條資料，每條資料大概多少位元組；
2.資料項：是否有大字段，那些欄位的值是否經常被更新；
3.資料查詢sql條件：哪些資料項的列名稱經常出現在where、group by、order by子句中等；
4.資料更新類sql條件：有多少列經常出現update或delete 的where子句中；
5.sql量的統計比，如：select：update+delete：insert=多少？
6.預計大表及相關聯的sql，每天總的執行量在何數量級？
7.表中的資料：更新為主的業務 還是 查詢為主的業務
8.打算採用什麼資料庫物理伺服器，以及資料庫伺服器架構？
9.併發如何？
10.儲存引擎選擇innodb還是myisam？
大致明白以上10個問題，至於如何設計此類的大表，應該什麼都清楚了！
至於優化若是指建立好的表，不能變動表結構的話，那建議innodb引擎，多利用點記憶體，減輕磁碟io負載，因為io往往是資料庫伺服器的瓶頸
另外對優化索引結構去解決效能問題的話，建議優先考慮修改類sql語句，使他們更快些，不得已只靠索引組織結構的方式，當然此話前提是，
索引已經建立的非常好，若是讀為主，可以考慮開啟query_cache，以及調整一些引數值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size
以及調整一些引數值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size
MySQL 對於千萬級的大表要怎麼優化？
很多人第一反應是各種切分 我給的順序是 第一優化你的sql和索引 第二加快取，memcached,redis 第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護 第四如果以上都做了還...
MySQL 對於千萬級的大表要怎麼優化？
對大資料的資料庫管理優化的總結 常用的 優化sql 突出快字，使完成操作的時間最短 1 用索引提高效率 2 選擇有效率的表名順序，及資料結構及欄位 3 使用decode函式可以避免重複掃瞄相同記錄或重複連線相同的表 4 刪除重複記 5 過內部函式提高sql效率 讀寫分離 操作不在乙個表裡完成 1 主...
MySQL 對於千萬級的大表要怎麼優化？
很多人第一反應是各種切分 我給的順序是 第一優化你的sql和索引 第二加快取，memcached,redis 第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護 第四如果以上都做了還...