MySQL資料庫開發規範 EC

庫名、表名、欄位名支援最多64個字元，但為了統一規範、易於辨識以及減少傳輸量，禁止超過32個字元

如tmp_t_crm_relation_0425。備份表也類似，形如 bak_t_***x_20160425 ，這樣便於查詢和知道有效期。

正常業務裡用的臨時表、中間表，字尾盡量不要包含 tmp 命名，以免造成歧義。

這也是為將來有可能分表做準備的，比如t_crm_ec_record_201403，但像 t_crm_contact_at201506就打破了這種規範。

不具有時間特性的，直接以t_tbname_001這樣的方式命名。

5.5版本開始mysql預設儲存引擎就是innodb，5.7版本開始，系統表都放棄myisam了。

即使2個表的字段有明確的外來鍵參考關係，也不使用 foreign key ，因為新紀錄會去主鍵表做校驗，影響效能。

觸發器（trigger）也是同樣，但也不應該通過它去約束資料的強一致性，mysql只支援「基於行的觸發」，也就是說，觸發器始終是針對一條記錄的，而不是針對整個sql語句的，如果變更的資料集非常大的話，效率會很低。掩蓋一條sql背後的工作，一旦出現問題將是災難性的，但又很難快速分析和定位。再者需要ddl時無法使用pt-osc工具。放在transaction執行。

事件（event）也是一種偷懶的表現，目前已經遇到數次由於定時任務執行失敗影響業務的情況，而且mysql無法對它做失敗預警。建立專門的 job scheduler 平台。

表字段數量不要超過20個，如果有需要建立主副表，主鍵一一關聯，避免單行資料過多以及修改記錄binlog row模式導致檔案過大。

特別對於有乙個text/blob或很大長度的varchar欄位時，更應考慮單獨儲存。但也要注意查詢條件盡量放在乙個表上。

建議使用 unsigned 儲存非負數值

相比不使用 unsigned，可以擴大一倍使用數值範圍

int使用固定4個位元組儲存，int(11)與int(4)只是顯示寬度的區別。但是定義是bigint(20), int(11)，不要隨便改動這個顯示寬度，c++裡面需要這個長度去擷取字段

使用decimal 代替float/double儲存精確浮點數

對於貨幣、金額這樣的型別，使用decimal，如 decimal(9,2)。float預設只能能精確到6位有效數字

比如不同表中都有 f_user_id 字段，那麼它的型別、字段長度要設計成一樣

盡量避免extra列出現：using file sort，using temporary，rows超過1000的要謹慎上線。

explain解讀

innodb儲存引擎中，secondary index(非主鍵索引，又稱為輔助索引、二級索引)沒有直接儲存行位址，而是儲存主鍵值。

如果使用者需要查詢secondary index中所不包含的資料列，則需要先通過secondary index查詢到主鍵值，然後再通過主鍵查詢到其他資料列，因此需要查詢兩次。覆蓋索引則可以在乙個索引中獲取所有需要的資料列，從而避免回表進行二次查詢，節省io因此效率較高。

例如select email，uid from user_email where uid=xx，如果uid不是主鍵，適當時候可以將索引新增為index(uid，email)，以獲得效能提公升。

如不在定義了 on update current_stamp 的列上建立索引，維護成本太高（好在mysql有insert buffer，會合併索引的插入）

修改表結構時 drop colum 時要注意，與這個字段相關的索引都會改變，變化是從原索引抽掉該欄位定義。這種情況有可能導致部分索引重複或失效。

即使需要所有字段，減少網路頻寬消耗，能有效利用覆蓋索引，表結構變更對程式基本無影響

在保證資料不會有誤的前提下，能確定結果集數量時，多使用limit，盡快的返回結果。

小於5.6版本時，子查詢效率很低，不像oracle那樣先計算子查詢後外層查詢。5.6版本開始得到優化

超過500個值使用批量的方式，否則一次執行會影響資料庫的併發能力，因為單sql只能且一直占用單cpu，而且可能導致主從複製延遲。

比如在乙個事務裡進行多個select，多個update，如果是高頻事務，會嚴重影響mysql併發能力，因為事務持有的鎖等資源只在事務rollback/commit時才能釋放。但同時也要權衡資料寫入的一致性。

不要再事務裡面做除資料庫以外的操作。

這種查詢更多的是通過索引去優化，但order by的字段有講究，比如主鍵id與f_time都是順序遞增，那就可以考慮order by id而非 f_time 。

與上面不同的是，order by之前有個範圍查詢，由前面的內容可知，用不到類似(c1,c2)的索引，但是可以利用(c2,c1)索引。另外還可以改寫成join的方式實現。

建議使用合理的分頁方式以提高分頁效率，大頁情況下不使用跳躍式分頁

假如有類似下面分頁語句:

select from table1 order by ftime desc limit 10000,10;

這種分頁方式會導致大量的io，因為mysql使用的是提前讀取策略。

推薦分頁方式：

select from table1 where ftime < last_time order by ftime desc limit 10

即傳入上一次分頁的界值

select * from table as t1 inner join (select id from table order by time limit 10000，10) as t2 on t1.id=t2.id

select最多導致資料庫慢，寫操作才是鎖表的罪魁禍首

是否應該 order by 主鍵

許多排序的場景，如果主鍵id是增長的，如果 order by f_create_time 查詢慢，有可能使用了filesort，此時最簡單的辦法是看能否換成 order by id，因為id作為主鍵是遞增的，並且附帶在了每個二級索引後面。

但是也要謹慎使用 order by id，特別是在explain結果看到filesort的情況下，優化器極有可能放棄這個filesort，而選擇了它所認為更高效的掃瞄方式，實則更慢。

使用正確的表

比如要統計昨天的資料這類業務較多，是否可以設計乙個昨天表，不在31天表上統計，在月份表上統計也行。

或者其它組已經有「半統計」的資料，從他們那抽取資料，而不是在原始資料上統計

這部分可另起一篇規範了，這裡先開個頭。

MySQL資料庫開發規範 EC

MySQL資料庫開發規範 EC

MYSQL資料庫開發規範

Mysql 資料庫開發規範

MySQL資料庫開發規範 EC

MySQL資料庫開發規範 EC

MYSQL資料庫開發規範

Mysql 資料庫開發規範

相關推薦