mysql設計規範和原則

DB設計流程：

1，需求分析

2，ER設計

3，物理設計

需求分析的最佳實踐是頭腦風暴，把需求理解透徹。根據公司的現況和將來的發展，與pm一塊兒來討論。

ER（EntiyRelation）設計階段要肯定各個模塊和模塊以前的關係，用來表達的語言就是ER圖，可讓人清晰的瞭解到表的設計和關係，工具用 workbench 來設計。

物理設計階段，須要作具體的技術選型，選擇合適的RDMS（好比Oracle、MySQL等等），設計表的字段類型，給表取一個 更好的名字。

物理設計的最佳實踐和總計：

    一、數據庫命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確(長度不能超過30個字符);
        例如：user, stat, log, 也能夠wifi_user, wifi_stat, wifi_log給數據庫加個前綴;
        除非是備份數據庫能夠加0-9的天然數：user_db_20151210;  

    二、數據庫表名命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確,多個單詞用下劃線'_'分隔;
        例如：user_login, user_profile, user_detail, user_role, user_role_relation,
            user_role_right, user_role_right_relation
        表前綴'user_'能夠有效的把相同關係的表顯示在一塊兒;
         
    三、數據庫表字段名命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確,多個單詞用下劃線'_'分隔;
        例如：user_login表字段 user_id, user_name, pass_word, eamil, tickit, status, mobile, add_time;
        每一個表中必須有自增主鍵,add_time(默認系統時間)
        表與表之間的相關聯字段名稱要求儘量的相同;
     
    四、數據庫表字段類型規範
        用盡可能少的存儲空間來存數一個字段的數據;
        例如：能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);
        IP地址最好使用int類型;
        固定長度的類型最好使用char,例如：郵編;
        能使用tinyint就不要使用smallint,int;
        最好給每一個字段一個默認值,最好不能爲null

    五、數據庫表索引規範
        命名簡潔明確,例如：user_login表user_name字段的索引應爲user_name_index惟一索引;
        爲每一個表建立一個主鍵索引;
        爲每一個表建立合理的索引;
        創建複合索引請慎重;

數據庫設計範式：

一，第一範式又稱爲1NF（First Normal Form），是對關係模式的基本要求，不知足第一範式的數據庫就不是關係數據庫。
數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。
同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。 若是出現重複的屬性，
就可能須要定義一個新的實體，新的實體由重複的屬性構成，新實體與原實體之間爲一對多關係。

簡而言之，第一範式就是沒有重複的列。

 二，第二範式（2NF）是在第一範式（1NF）的基礎上創建起來的，即知足第二範式必須先知足第一範式（1NF）。
 第二範式要求數據庫表中的每一個實例或行必須能夠被惟一地區分。爲實現區分一般須要爲表加上一個列，以存儲各個實例的唯一標識。

簡而言之，第二範式就是屬性應徹底依賴於其主鍵。

 

三，知足第三範式（3NF）必須先知足第二範式（2NF）。第三範式要求數據表中若是不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴。
所謂傳遞函數依賴，指的是若是存在"A → B → C"的決定關係，則C傳遞函數依賴於A。

簡而言之，第三範式就是任一非主鍵屬性不該依賴於其它任何非主鍵屬性。它是對字段冗餘性的約束，即任何字段不能由其餘字段派生出來，它要求字段沒有冗餘

數據表的關係：

在關係型數據庫中，弄清各個模塊（或者叫實體或者叫表）之間的關係很是重要。關係型數據庫中有三種基本關係：

1. 1 - 1，好比一個國家對應一個首都
2. 1 - N，好比一個分類下能夠有多個商品，一個班級有多個學生，這種關係每每存在從屬關係
3. N - N，好比學生和課程，一個學生能夠選多門課，不一樣的學生也能夠選擇同一門課

數據庫設計原則：

1. 通常表除了「語義上」的主鍵以外最好有一個自增主鍵
2. 避免使用外鍵約束，觸發器
3. 不要用預留字段
4. 反範式設計提升效率

詳細解析：

一、核心原則
        不在數據庫作運算;
        cpu計算務必移至業務層;
        控制列數量(字段少而精,字段數建議在20之內);
        平衡範式與冗餘(效率優先；每每犧牲範式)
        拒絕3B(拒絕大sql語句：big sql、拒絕大事物：big transaction、拒絕大批量：big batch);
 
    二、字段類原則
        用好數值類型(用合適的字段類型節約空間);
        字符轉化爲數字(能轉化的最好轉化,一樣節約空間、提升查詢性能);
        避免使用NULL字段(NULL字段很難查詢優化、NULL字段的索引須要額外空間、NULL字段的複合索引無效);
        少用text類型(儘可能使用varchar代替text字段);
     
    三、索引類原則
        合理使用索引(改善查詢,減慢更新,索引必定不是越多越好);
        字符字段必須建前綴索引;
        不在索引作列運算;
        innodb主鍵推薦使用自增列(主鍵創建聚簇索引,主鍵不該該被修改,字符串不該該作主鍵)(理解Innodb的索引保存結構就知道了);
        不用外鍵(由程序保證約束);
     
    四、sql類原則
        sql語句儘量簡單(一條sql只能在一個cpu運算,大語句拆小語句,減小鎖時間,一條大sql能夠堵死整個庫);
        簡單的事務;
        避免使用trig/func(觸發器、函數不用客戶端程序取而代之);
        不用select *(消耗cpu,io,內存,帶寬,這種程序不具備擴展性);
        OR改寫爲IN(or的效率是n級別);
        OR改寫爲UNION(mysql的索引合併很弱智);
            select id from t where phone = ’159′ or name = ‘john’;
            =>
            select id from t where phone=’159′
            union
            select id from t where name=’jonh’
        避免負向% ;
        limit高效分頁(limit越大，效率越低);
        使用union all替代union(union有去重開銷);
        少用鏈接join;
        使用group by;
        請使用同類型比較;
        打散批量更新;