您好,登錄后才能下訂單哦!
這篇文章主要介紹“MySQL命名規范是什么”,在日常操作中,相信很多人在MySQL命名規范是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”MySQL命名規范是什么”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
所有數據庫對象名稱必須使用小寫字母并用下劃線分割。
所有數據庫對象名稱禁止使用 MySQL 保留關鍵字(如果表名中包含關鍵字查詢時,需要將其用單引號括起來)。
數據庫對象的命名要能做到見名識意,并且最后不要超過3 2 個字符。
臨時庫表必須以 tmp_ 為前綴并以日期為后綴,備份表必須以 bak_ 為前綴并以日期 ( 時間戳 ) 為后綴。
所有存儲相同數據的列名和列類型必須一致(一般作為關聯列,如果查詢時關聯列類型不一致會自動進行數據類型隱式轉換,會造成列上的索引失效,導致查詢效率降低)。
二、數據庫基本設計規范
所有表必須使用 InnoDB 存儲引擎沒有特殊要求(即 InnoDB 無法滿足的功能如:列存儲,存儲空間數據等)的情況下,所有表必須使用 InnoDB 存儲引擎(MySQL 5.5 之前默認使用 Myisam,5.6 以后默認的為 InnoDB)InnoDB 支持事務,支持行級鎖,更好的恢復性,高并發下性能更好。
數據庫和表的字符集統一使用 UTF8兼容性更好,統一字符集可以避免由于字符集轉換產生的亂碼,不同的字符集進行比較前需要進行轉換會造成索引失效。
所有表和字段都需要添加注釋使用 comment 從句添加表和列的備注 從一開始就進行數據字典的維護。
盡量控制單表數據量的大小,建議控制在 500 萬以內
500 萬并不是 MySQL 數據庫的限制,過大會造成修改表結構、備份、恢復都會有很大的問題,可以用歷史數據歸檔(應用于日志數據),分庫分表(應用于業務數據)等手段來控制數據量大小。
謹慎使用 MySQL 分區表
分區表在物理上表現為多個文件,在邏輯上表現為一個表 謹慎選擇分區鍵,跨分區查詢效率可能更低 建議采用物理分表的方式管理大數據。
盡量做到冷熱數據分離,減小表的寬度
MySQL 限制每個表最多存儲 4096 列,并且每一行數據的大小不能超過 65535 字節 減少磁盤 IO,保證熱數據的內存緩存命中率(表越寬,把表裝載進內存緩沖池時所占用的內存也就越大,也會消耗更多的 IO) 更有效的利用緩存,避免讀入無用的冷數據 經常一起使用的列放到一個表中(避免更多的關聯操作)
7.禁止在表中建立預留字段預留字段的命名很難做到見名識義 預留字段無法確認存儲的數據類型,所以無法選擇合適的類型 對預留字段類型的修改,會對表進行鎖定
8.禁止在數據庫中存儲圖片,文件等大的二進制數據通常文件很大,會短時間內造成數據量快速增長,數據庫進行數據庫讀取時,通常會進行大量的隨機 IO 操作,文件很大時,IO 操作很耗時 通常存儲于文件服務器,數據庫只存儲文件地址信息。
9.禁止在線上做數據庫壓力測試
10.禁止從開發環境,測試環境直接連接生成環境數據庫
三、數據庫字段設計規范
原因
列的字段越大,建立索引時所需要的空間也就越大,這樣一頁中所能存儲的索引節點的數量也就越少也越少,在遍歷時所需要的IO次數也就越多, 索引的性能也就越差
方法
將字符串轉換成數字類型存儲,如:
將IP地址轉換成整形數據。
MySQL 提供了兩個方法來處理 IP 地址:
inet_aton 把ip轉為無符號整型(4-8位)inet_ntoa 把整型的ip轉為地址
插入數據前,先用 inet_aton 把 IP 地址轉為整型,可以節省空間。
顯示數據時,使用 inet_ntoa 把整型的 IP 地址轉為地址顯示即可
2.對于非負型的數據(如自增 ID、整型 IP)來說,要優先使用無符號整型來存儲
因為無符號相對于有符號可以多出一倍的存儲空間。
SIGNED INT -2147483648~2147483647UNSIGNED INT 0~4294967295
VARCHAR(N) 中的 N 代表的是字符數,而不是字節數。使用 UTF8 存儲 255 個漢字 Varchar(255)=765 個字節。過大的長度會消耗更多的內存
建議把 BLOB 或是TEXT列分離到單獨的擴展表中
MySQL 內存臨時表不支持 TEXT、BLOB 這樣的大數據類型,如果查詢中包含這樣的數據,在排序等操作時,就不能使用內存臨時表,必須使用磁盤臨時表進行。
而且對于這種數據,MySQL 還是要進行二次查詢,會使 SQL 性能變得很差,但是不是說一定不能使用這樣的數據類型。
如果一定要使用,建議把 BLOB 或是 TEXT 列分離到單獨的擴展表中,查詢時一定不要使用 select * 而只需要取出必要的列,不需要 TEXT 列的數據時不要對該列進行查詢。
TEXT 或 BLOB 類型只能使用前綴索引
因為 MySQL 對索引字段長度是有限制的,所以 TEXT 類型只能使用前綴索引,并且 TEXT 列上是不能有默認值的。
修改 ENUM 值需要使用 ALTER 語句
ENUM 類型的 ORDER BY 操作效率低,需要額外操作
禁止使用數值作為 ENUM 的枚舉值
4. 盡可能把所有列定義為 NOT NULL
原因:
索引 NULL 列需要額外的空間來保存,所以要占用更多的空間。
進行比較和計算時要對 NULL 值做特別的處理。
5. 使用 TIMESTAMP(4 個字節)或 DATETIME 類型(8 個字節)存儲時間
TIMESTAMP 存儲的時間范圍 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。
TIMESTAMP 占用 4 字節和 INT 相同,但比 INT 可讀性高,超出 TIMESTAMP 取值范圍的使用 DATETIME 類型存儲。
經常會有人用字符串存儲日期型的數據(不正確的做法):
缺點 1:無法用日期函數進行計算和比較。
缺點 2:用字符串存儲日期要占用更多的空間。
6. 同財務相關的金額類數據必須使用 decimal 類型
非精準浮點:float,double
精準浮點:decimal
Decimal 類型為精準浮點數,在計算時不會丟失精度。占用空間由定義的寬度決定,每 4 個字節可以存儲 9 位數字,并且小數點要占用一個字節。可用于存儲比 bigint 更大的整型數據。
索引并不是越多越好!索引可以提高效率同樣也可以降低效率;索引可以增加查詢效率,但同樣也會降低插入和更新的效率,甚至有些情況下會降低查詢效率。
因為 MySQL 優化器在選擇如何優化查詢時,會根據統一信息,對每一個可以用到的索引來進行評估,以生成出一個最好的執行計劃,如果同時有很多個索引都可以用于查詢,就會增加 MySQL 優化器生成執行計劃的時間,同樣會降低查詢性能。
5.6 版本之前,一個 SQL 只能使用到一個表中的一個索引,5.6 以后,雖然有了合并索引的優化方式,但是還是遠遠沒有使用一個聯合索引的查詢方式好
InnoDB 是一種索引組織表:數據的存儲的邏輯順序和索引的順序是相同的。每個表都可以有多個索引,但是表的存儲順序只能有一種 InnoDB是按照主鍵索引的順序來組織表的。
不要使用更新頻繁的列作為主鍵,不適用多列主鍵(相當于聯合索引) 不要使用 UUID、MD5、HASH、字符串列作為主鍵(無法保證數據的順序增長)。主鍵建議使用自增 ID 值。
出現在 SELECT、UPDATE、DELETE 語句的 WHERE 從句中的列。
包含在 ORDER BY、GROUP BY、DISTINCT 中的字段。
并不要將符合 1 和 2 中的字段的列都建立一個索引,通常將 1、2 中的字段建立聯合索引效果更好。
多表 JOIN 的關聯列。
到此,關于“MySQL命名規范是什么”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。