1.一般情況可以選擇MyISAM存儲引擎，如果需要食物支持必須使用InnoDB存儲引擎。

MyISAM 存儲引擎B-tree索引有個很大的限制：參與一個索引的所有字段的長度之和不能超過1000字節。另外MyISAM數據和索引是分開，而InnoDB的數據存儲是按聚簇索引有序排列的，主鍵是默認的聚簇索引，因此MyISAM雖然在一般情況下，查詢性能比InnoDB高，但InnoDB的以主鍵為條件的查詢性能是非常高的。

2.命名規則

數據庫和表名應盡可能和所服務的業務模塊名一致。

服務與同一個子模塊的一類表應盡量以子模塊名。

表名應盡量包含與所存放數據對應的單詞。

字段名稱應盡量保持和實際數據相對應。

聯合索引名稱應盡量包含所有索引鍵字段名或縮寫。

約束等其他對象也應該盡可能包含所屬表或其他對象的名稱。

3.數據庫字段類型定義

經常需要計算和排序等消耗CPU的字段，應該盡量選擇更為迅速的字段，如 TIMESTAMP(4個字節)代替Datetime(8個字節)，通過整形替代浮點型和字符型

變長字段使用varchar,不要使用char

對于二進制多媒體數據，流水隊列數據，超大文本數據不要放在數據庫字段中

4.業務邏輯執行過程必須讀到的表中必須要有初始的值。避免業務讀出為負或無窮大的值導致程序失敗。

5.并不需要一定遵守凡是理論，適度的冗余，讓查詢盡量減少join

6.訪問頻率較低的大字段拆分出數據表。有些大字段占用空間多，訪問頻率較其他字段明顯要少得很多，這種情況進行拆分，頻繁的查詢中就不需要讀取大字段，造成IO資源的浪費。

7.大表可以考慮水平拆分。大表影響查詢效率，根據業務特性有很多拆分方式，根據時間遞增的數據，可以根據時間來分。以id劃分的數據，可以根據 id % 數據庫個數的方式來拆分。

數據庫索引

8.業務需要的相關索引是根據實際的設計所構造sql語句的where條件來確定，業務不需要的不要建索引，不允許在聯合索引中存在多余的字段。特別是該字段根本不會再條件語句中出現。

9.唯一確定一條記錄的一個字段或多個字段要建立主鍵或唯一索引，不能唯一確定一條記錄，為了提高查詢效率建普通索引。

10.業務使用的表，有些記錄數很少，甚至只有一條記錄，為了約束的需要，也要建立索引或者設置主鍵。

11.對于取值不能重復，經常作為查詢條件的字段，應該建唯一索引，并且將查詢條件中該字段的條件置于第一個位置。沒有必要再建立與該字段有關的聯合索引。

12.對于經常查詢的字段，其值不唯一，應考慮建立普通索引，查詢語句中該字段條件置于第一個位置，對聯合索引處理的方法相同。

13.業務通過不唯一索引訪問數據時，需要考慮通過該索引值返回的記錄稠密度，原則上可能的稠密度最大不能高于0.2，如果稠密度太大，則不合適建立索引。

14.需要聯合索引的數據庫要注意索引的順序。SQL語句中的匹配條件也要跟索引的順序保持一致。

15.表中的多個字段查詢作為查詢條件，不含有其他索引，并且字段聯合值不重復，可以在這多個字段上建唯一的聯合索引。

16.重要業務訪問數據表時。但不能通過索引訪問數據時，應該確保順序訪問的記錄數目是有限的，原則上不得多于10。

查詢語句與應用系統優化

17.合理構造Query語句

insert語句中，根據測試，批量一次插入1000條時效率最高，多于1000條時，要拆分，多次進行同樣的插入，應該合并批量進行。

查詢條件中各種邏輯操作符性能順序是and，or ，in 因此在查詢中應該盡量避免使用在大集合中使用 in

永遠用小結果集驅動大記錄集，因為在mysql中，join是通過嵌套循環來實現的。

只取需要的columns，盡量不要使用select *。

僅僅使用最有效的過濾字段，where字句中的過濾條件少為好。

盡量避免復雜的join和子查詢。

18.應用系統的優化

合理使用cache，對于變化較少的部分活躍數據通過應用層的cache緩存到內存中，對性能的提升是成數量級的。

對重復執行相同的query進行合并，減少IO次數。

事務相關性最小原則。

總結

以上是生活随笔為你收集整理的mysql的FIQ怎么安装_MySQL数据库设计总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。