本文目錄一覽:
北大青鳥設計培訓:Mysql數據庫的設計和優化?
在JAVA開發中數據庫的學習也是我們需要了解的,截下來幾篇文章都是關於數據庫的設計和應用,那麼java課程培訓機構廢話不多說開始學習吧! 數據庫的設計 數據庫設計是基礎,數據庫優化是建立在設計基礎之上的。
好的數據庫一定擁有好的設計。
數據庫設計的目標是為用戶和各種應用系統提供一個信息基礎設施和高效的運行環境。
數據庫的三大範式 第一範式1NF:所有的域都應該是原子性的,即數據庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。
第二範式2Nf:第二範式在第一範式的基礎之上更進一層。
第二範式需要確保數據庫表中的每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。
也就是說在一個數據庫表中,一個表中只能保存一種數據,不可以把多種數據保存在同一張數據庫表中。
第三範式3Nf:所有字段必須與主鍵直接相關,而不是間接相關。
也可以理解為字段不要和其他非主鍵字段相關. 注意:這三個範式儘可能去遵守,不是一定要墨守成規.這只是讓我們設計的表的時候,越靠近這些範式,可以使字段盡量的減小冗餘.但是有時候也可以根據實際需要小小的違背一下.但是第三範式違反一下還可以接受,但是第一範式別違反. 數據庫設計的步驟 需求分析階段 準確了解與分析用戶需求(包括數據與處理)。
是整個設計過程的基礎,是最困難、最耗費時間的一步。
概念結構設計階段 是整個數據庫設計的關鍵–設計數據庫的E-R模型圖,確認需求信息的正確和完整 Entity_Relationship—實體之間的關係 一對一 一對多 多對一
扛得住的MySQL數據庫架構
數據庫優化是系統工程,性能的提升靠整體。本課程將面面俱到的講解提升數據庫性能的各種因素,讓你在最短的時間從小白到資深,將數據庫整體架構瞭然於胸
第1章 實例和故事 試看7 節 | 50分鐘
決定電商11大促成敗的各個關鍵因素。
收起列表
視頻:1-1 什麼決定了電商雙11大促的成敗 (04:04)試看
視頻:1-2 在雙11大促中的數據庫服務器 (06:03)
視頻:1-3 在大促中什麼影響了數據庫性能 (07:55)
視頻:1-4 大錶帶來的問題 (14:13)
視頻:1-5 大事務帶來的問題 (17:27)
作業:1-6 【討論題】在日常工作中如何應對高並發大數據量對數據庫性能挑戰
作業:1-7 【討論題】在MySQL中事務的作用是什麼?
第2章 什麼影響了MySQL性能 試看30 節 | 210分鐘
詳細介紹影響性能各個因素,包括硬件、操作系統等等。
收起列表
視頻:2-1 影響性能的幾個方面 (04:08)試看
視頻:2-2 CPU資源和可用內存大小 (10:54)
視頻:2-3 磁盤的配置和選擇 (04:44)
視頻:2-4 使用RAID增加傳統機器硬盤的性能 (11:30)
視頻:2-5 使用固態存儲SSD或PCIe卡 (08:35)
視頻:2-6 使用網絡存儲SAN和NAS (07:16)
視頻:2-7 總結:服務器硬件對性能的影響 (03:27)
視頻:2-8 操作系統對性能的影響-MySQL適合的操作系統 (03:50)
視頻:2-9 CentOS系統參數優化 (11:43)
視頻:2-10 文件系統對性能的影響 (03:29)
視頻:2-11 MySQL體系結構 (05:29)
視頻:2-12 MySQL常用存儲引擎之MyISAM (13:23)
視頻:2-13 MySQL常用存儲引擎之Innodb (10:44)
視頻:2-14 Innodb存儲引擎的特性(1) (15:24)
視頻:2-15 Innodb存儲引擎的特性(2) (08:44)
視頻:2-16 MySQL常用存儲引擎之CSV (09:19)
視頻:2-17 MySQL常用存儲引擎之Archive (06:08)
視頻:2-18 MySQL常用存儲引擎之Memory (10:40)
視頻:2-19 MySQL常用存儲引擎之Federated (11:21)
視頻:2-20 如何選擇存儲引擎 (04:33)
視頻:2-21 MySQL服務器參數介紹 (08:04)
視頻:2-22 內存配置相關參數 (09:24)
視頻:2-23 IO相關配置參數 (10:01)
視頻:2-24 安全相關配置參數 (06:13)
視頻:2-25 其它常用配置參數 (03:41)
視頻:2-26 數據庫設計對性能的影響 (04:36)
視頻:2-27 總結 (01:32)
作業:2-28 【討論題】你會如何配置公司的數據庫服務器硬件?
作業:2-29 【討論題】你認為對數據庫性能影響最大的因素是什麼
作業:2-30 【討論題】做為電商的DBA,建議開發選哪種MySQL存儲引擎
第3章 MySQL基準測試8 節 | 65分鐘
了解基準測試,MySQL基準測試工具介紹及實例演示。
收起列表
視頻:3-1 什麼是基準測試 (02:20)
視頻:3-2 如何進行基準測試 (09:00)
視頻:3-3 基準測試演示實例 (11:18)
視頻:3-4 Mysql基準測試工具之mysqlslap (13:30)
視頻:3-5 Mysql基準測試工具之sysbench (11:07)
視頻:3-6 sysbench基準測試演示實例 (17:11)
作業:3-7 【討論題】MySQL基準測試是否可以體現出業務系統的真實性能
作業:3-8 【實操題】參數不同取值對性能的影響
第4章 MySQL數據庫結構優化14 節 | 85分鐘
詳細介紹數據庫結構設計、範式和反範式設計、物理設計等等。
收起列表
視頻:4-1 數據庫結構優化介紹 (06:52)
視頻:4-2 數據庫結構設計 (14:49)
視頻:4-3 需求分析及邏輯設計 (11:00)
視頻:4-4 需求分析及邏輯設計-反範式化設計 (06:44)
視頻:4-5 範式化設計和反範式化設計優缺點 (04:06)
視頻:4-6 物理設計介紹 (05:17)
視頻:4-7 物理設計-數據類型的選擇 (18:59)
視頻:4-8 物理設計-如何存儲日期類型 (13:37)
視頻:4-9 物理設計-總結 (02:37)
圖文:4-10 說明MyISAM和Innodb存儲引擎的5點不同
作業:4-11 【討論題】判斷表結構是否符合第三範式要求?如不滿足要如何修改
作業:4-12 【實操題】請設計一個電商訂單系統的數據庫結構
作業:4-13 【討論題】以下那個字段適合作為Innodb表的主建使用
作業:4-14 【討論題】請為下表中的字段選擇合適的數據類型
第5章 MySQL高可用架構設計 試看24 節 | 249分鐘
詳細介紹二進制日誌及其對複製的影響、GTID的複製、MMM、MHA等等。
收起列表
視頻:5-1 mysql複製功能介紹 (04:58)
視頻:5-2 mysql二進制日誌 (22:05)
視頻:5-3 mysql二進制日誌格式對複製的影響 (09:37)
視頻:5-4 mysql複製工作方式 (03:08)
視頻:5-5 基於日誌點的複製 (20:06)
視頻:5-6 基於GTID的複製 (22:32)
視頻:5-7 MySQL複製拓撲 (13:58)
視頻:5-8 MySQL複製性能優化 (09:23)
視頻:5-9 MySQL複製常見問題處理 (08:31)
視頻:5-10 什麼是高可用架構 (14:09)
視頻:5-11 MMM架構介紹 (08:09)
視頻:5-12 MMM架構實例演示(上) (09:16)試看
視頻:5-13 MMM架構實例演示(下) (18:55)
視頻:5-14 MMM架構的優缺點 (08:01)
視頻:5-15 MHA架構介紹 (10:02)
視頻:5-16 MHA架構實例演示(1) (13:11)
視頻:5-17 MHA架構實例演示(2) (16:54)
視頻:5-18 MHA架構優缺點 (05:14)
視頻:5-19 讀寫分離和負載均衡介紹 (11:42)
視頻:5-20 MaxScale實例演示 (18:25)
作業:5-21 【討論題】MySQL主從複製為什麼會有延遲,延遲又是如何產生
作業:5-22 【實操題】請為某互聯網項目設計99.99%MySQL架構
作業:5-23 【討論題】如何給一個已經存在的主從複製集群新增一個從節點
作業:5-24 【討論題】給你三台數據庫服務器,你如何設計它的高可用架構
第6章 數據庫索引優化8 節 | 65分鐘
介紹BTree索引和Hash索引,詳細介紹索引的優化策略等等。
收起列表
視頻:6-1 Btree索引和Hash索引 (20:09)
視頻:6-2 安裝演示數據庫 (01:19)
視頻:6-3 索引優化策略(上) (17:33)
視頻:6-4 索引優化策略(中) (13:02)
視頻:6-5 索引優化策略(下) (12:30)
作業:6-6 【討論題】一列上建立了索引,查詢時就一定會用到這個索引嗎
作業:6-7 【討論題】在定義聯合索引時為什麼需要注意聯合索引中的順序
作業:6-8 【實操題】SQL建立索引,你會考慮那些因素
第7章 SQL查詢優化9 節 | 62分鐘
詳細介紹慢查詢日誌及示例演示,MySQL查詢優化器介紹及特定SQL的查詢優化等。
收起列表
視頻:7-1 獲取有性能問題SQL的三種方法 (05:14)
視頻:7-2 慢查詢日誌介紹 (08:57)
視頻:7-3 慢查詢日誌實例 (08:27)
視頻:7-4 實時獲取性能問題SQL (02:21)
視頻:7-5 SQL的解析預處理及生成執行計劃 (16:02)
視頻:7-6 如何確定查詢處理各個階段所消耗的時間 (09:35)
視頻:7-7 特定SQL的查詢優化 (10:34)
作業:7-8 【討論題】如何跟據需要對一個大表中的數據進行刪除或更新
作業:7-9 【討論題】如何獲取需要優化的SQL查詢
第8章 數據庫的分庫分表5 節 | 48分鐘
詳細介紹數據庫分庫分表的實現原理及演示案例等。
收起列表
視頻:8-1 數據庫分庫分表的幾種方式 (04:34)
視頻:8-2 數據庫分片前的準備 (13:53)
視頻:8-3 數據庫分片演示(上) (11:40)
視頻:8-4 數據庫分片演示(下) (17:02)
作業:8-5 【討論題】對於大表來說我們一定要進行分庫分表嗎
第9章 數據庫監控7 節 | 29分鐘
介紹數據庫可用性監控、性能監控、MySQL主從複製監控等
收起列表
視頻:9-1 數據庫監控介紹 (04:46)
視頻:9-2 數據庫可用性監控 (07:20)
視頻:9-3 數據庫性能監控 (09:39)
視頻:9-4 MySQL主從複製監控 (06:16)
作業:9-5 【討論題】QPS是否可以真實的反映出數據庫的負載情況
作業:9-6 【討論題】如何正確評估數據庫的當前負載狀況
作業:9-7 【實操題】開發一個簡單監控腳本,監控mySQL數據庫阻塞情況
數據庫表結構設計,常見的數據庫管理系統
一、數據場景 1、表結構簡介 任何工具類的東西都是為了解決某個場景下的問題,比如Redis緩存系統熱點數據,ClickHouse解決海量數據的實時分析,MySQL關係型數據庫存儲結構化數據。數據的存儲則需要設計對應的表結構,清楚的表結構,有助於快速開發業務,和理解系統。表結構的設計通常從下面幾個方面考慮:業務場景、設計規範、表結構、字段屬性、數據管理。
2、用戶場景
例如存儲用戶基礎信息數據,通常都會下面幾個相關表結構:用戶信息表、單點登錄表、狀態管理表、支付賬戶表等。
用戶信息表
存儲用戶三要素相關信息:姓名,手機號,身份證,登錄密碼,郵箱等。
CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT ‘用戶ID’, `user_name` varchar(20) NOT NULL COMMENT ‘用戶名’, `real_name` varchar(20) DEFAULT NULL COMMENT ‘真實姓名’, `pass_word` varchar(32) NOT NULL COMMENT ‘密碼’, `phone` varchar(20) NOT NULL COMMENT ‘手機號’, `email` varchar(32) DEFAULT NULL COMMENT ‘郵箱’, `head_url` varchar(100) DEFAULT NULL COMMENT ‘用戶頭像URL’, `card_id` varchar(32) DEFAULT NULL COMMENT ‘身份證號’, `user_sex` int(1) DEFAULT ‘1’ COMMENT ‘用戶性別:0-女,1-男’, `create_time` datetime DEFAULT NULL COMMENT ‘創建時間’, `update_time` datetime DEFAULT NULL COMMENT ‘更新時間’, `state` int(1) DEFAULT ‘1’ COMMENT ‘是否可用,0-不可用,1-可用’, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’用戶表’; 單點登錄表
用意是在多個業務系統中,用戶登錄一次就可以訪問所有相互信任的業務子系統,是聚合業務平台常用的解決方案。
CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT ‘用戶ID’, `sso_id` varchar(32) NOT NULL COMMENT ‘單點信息編號ID’, `sso_code` varchar(32) NOT NULL COMMENT ‘單點登錄碼,唯一核心標識’, `log_ip` varchar(32) DEFAULT NULL COMMENT ‘登錄IP地址’, `create_time` datetime DEFAULT NULL COMMENT ‘創建時間’, `update_time` datetime DEFAULT NULL COMMENT ‘更新時間’, `state` int(1) DEFAULT ‘1’ COMMENT ‘是否可用,0-不可用,1-可用’, PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’用戶單點登錄表’; 狀態管理表
系統用戶在使用時候可能出現多個狀態,例如賬戶凍結、密碼鎖定等,把狀態聚合到一起,可以更加方便的管理和驗證。
CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT ‘用戶ID’, `account_status` int(1) DEFAULT ‘1’ COMMENT ‘賬戶狀態:0-凍結,1-未凍結’, `real_name_status` int(1) DEFAULT ‘0’ COMMENT ‘實名認證狀態:0-未實名,1-已實名’, `pay_pass_status` int(1) DEFAULT ‘0’ COMMENT ‘支付密碼是否設置:0-未設置,1-設置’, `wallet_pass_status` int(1) DEFAULT ‘0’ COMMENT ‘錢包密碼是否設置:0-未設置,1-設置’, `wallet_status` int(1) DEFAULT ‘1’ COMMENT ‘錢包是否凍結:0-凍結,1-未凍結’, `email_status` int(1) DEFAULT ‘0’ COMMENT ‘郵箱狀態:0-未激活,1-激活’, `message_status` int(1) DEFAULT ‘1’ COMMENT ‘短訊提醒開啟:0-未開啟,1-開啟’, `letter_status` int(1) DEFAULT ‘1’ COMMENT ‘站內信提醒開啟:0-未開啟,1-開啟’, `emailmsg_status` int(1) DEFAULT ‘0’ COMMENT ‘郵件提醒開啟:0-未開啟,1-開啟’, `create_time` datetime DEFAULT NULL COMMENT ‘創建時間’, `update_time` datetime DEFAULT NULL COMMENT ‘更新時間’, `state` int(1) DEFAULT ‘1’ COMMENT ‘是否可用,0-不可用,1-可用’, PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’用戶狀態表’; 支付賬戶表
用戶交易的核心表,存儲用戶相關的賬戶資金信息。
CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT ‘錢包ID’, `user_id` int(11) NOT NULL COMMENT ‘用戶ID’, `wallet_pwd` varchar(32) DEFAULT NULL COMMENT ‘錢包密碼’, `total_account` decimal(20,2) DEFAULT ‘0.00’ COMMENT ‘賬戶總額’, `usable_money` decimal(20,2) DEFAULT ‘0.00’ COMMENT ‘可用餘額’, `freeze_money` decimal(20,2) DEFAULT ‘0.00’ COMMENT ‘凍結金額’, `freeze_time` datetime DEFAULT NULL COMMENT ‘凍結時間’, `thaw_time` datetime DEFAULT NULL COMMENT ‘解凍時間’, `create_time` datetime DEFAULT NULL COMMENT ‘創建時間’, `update_time` datetime DEFAULT NULL COMMENT ‘更新時間’, `state` int(1) DEFAULT ‘1’ COMMENT ‘是否可用,0-不可用,1-可用’, PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’用戶錢包’; 二、設計規範 1、涉及模塊
通過上面幾個表設計的案例,可以看到表設計關聯到數據庫的各個方面知識:數據類型,索引,編碼,存儲引擎等。表設計是一個很大的命題,不過也遵循一個基本規範:三範式。
2、三範式 基礎概念
一範式
表的列的具有原子性,不可再分解,即列的信息,不能分解,關係型數據庫MySQL、Oracle等自動的滿足。
二範式
每個事實的數據記錄只會出現一次, 不會冗餘, 通常設計一個主鍵來實現。
三範式
要求一個表中不包含已經存在於其它表的非主鍵信息,例如部門和員工的信息,員工表包含部門表的主鍵ID,則可以關聯獲取相關信息,沒必要在員工表保存相關信息。
優缺點對比
範式化設計
範式化結構設計通常更新快,因為冗餘數據較少,表結構輕巧,也更好的寫入內存中。但是查詢起來涉及到關聯,代價非常高,非常損耗查詢性能。
反範式化設計
所有的數據都在一張表中,避免關聯查詢,索引的有效性更高,但是數據的冗餘性極高。
建議結論
上述的兩種設計方式在實際開發中都是不存在的,在實際開發中都是混合使用。比如匯總統計,緩存數據,都會基於反範式化的設計。
三、字段屬性
合適的字段類型對於高性能來說非常重要,基本原則如下:簡單的類型佔用資源更少;在可以正確存儲數據的情況下,選最小的數據類型。
1、數據類型選擇 整數類型
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT,根據數據類型範圍合理選擇即可。
實數類型
FLOAT、DOUBLE、DECIMAL,建議資金貨幣相關類型使用高精度DECIMAL存儲,或者把數據成倍擴大為整數,採用BIGINT存儲,不過處理相對麻煩。
字符類型
CHAR、VARCHAR,長度不確定建議採用VARCHAR存儲,不過VARCHAR類型需要額外開銷記錄字符串長度。CHAR適合存儲短字符,或者定長字符串,例如MD5的加密結構。
時間類型
DATETIME、TIMESTAMP,DATETIME保存大範圍的值,精度秒。TIMESTAMP以時間戳的格式,範圍相對較小,效率也相對較高,所以通常情況建議使用。
MySQL的字段類型有很多種,可以根據數據特性選擇合適的,這裡只描述常見的幾種類型。
2、基礎用法操作 數據類型
修改字段類型
ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT ‘0’ ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT ‘1’ COMMENT ‘狀態:0不可用,1可用’;
修改名稱位置
ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用
索引類型:主鍵索引,普通索引,唯一索引,組合索引,全文索引。這裡演示普通索引的操作。MySQL的核心模塊,後續詳說。
添加索引
ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;
查看索引
SHOW INDEX FROM ms_user_wallet;
刪除索引
DROP INDEX state_index ON ms_user_wallet ;
修改索引
不具有真正意義上的修改,可以把原有的索引刪除之後,再次添加索引。
外鍵關聯
用處:外鍵關聯的作用保證多個數據表的數據一致性和完整性,建表時先有主表,後有從表;刪除數據表,需要先刪從表,再刪主表。複雜場景不建議使用,實際開發中用的也不多。
添加外鍵
ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;
刪除外鍵
ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表結構管理 1、查看結構 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、字段結構 添加字段 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT ‘刪除時間’ ; 刪除字段 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存儲引擎 存儲引擎 SELECT VERSION() ; SHOW ENGINES ;
MySQL 5.6 支持的存儲引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默認使用InnoDB,支持事務管理。該模塊MySQL核心,後續詳解。
修改引擎
數據量大的場景下,存儲引擎修改是一個難度極大的操作,容易會導致表的特性變動,引起各種後續反應,後續會詳說。
ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改編碼
表字符集默認使用utf8,通用,無亂碼風險,漢字3位元組,英文1位元組,utf8mb4是utf8的超集,有存儲4位元組例如表情符號時使用。
查看編碼 SHOW VARIABLES LIKE ‘character%’; 修改編碼 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、數據管理 1、增刪改查
添加數據
INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( ‘1’,’SSO7637267′,’SSO78631273612′, ‘2019-12-24 11:56:57′,’2019-12-24 11:57:01′,’127.0.0.1′,’1’ );
更新數據
UPDATE ms_user_sso SET user_id = ‘1’,sso_id = ‘SSO20191224’,sso_code = ‘SSO20191224’, create_time = ‘2019-11-24 11:56:57’,update_time = ‘2019-11-24 11:57:01’, login_ip = ‘127.0.0.1’,state = ‘1’ WHERE user_id = ‘1’;
查詢數據
一般情況下都是禁止使用 select* 操作。
SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = ‘1’;
刪除數據
DELETE FROM ms_user_sso WHERE user_id = ‘2’ ;
不帶where條件,就是刪除全部數據。原則上不允許該操作,優化篇會詳解。TRUNCATE TABLE也是清空表數據,但是佔用的資源相對較少。
2、數據安全 不可逆加密
這類加密算法,多用來做數據驗證操作,比如常見的密碼驗證。
SELECT MD5(‘cicada’)=’94454b1241ad2cfbd0c44efda1b6b6ba’ ; SELECT SHA(‘cicada’)=’0501746a2e4fd34e1d14015fc4d58309585edc7d’; SELECT PASSWORD(‘smile’)=’*B4FB95D86DCFC3F33A3852714DC742C77504479D’ ; 可逆加密
安全性要求高的系統,需要做三級等保,對數據的安全性極高,數據在存儲時必須加密入庫,取出時候需要解密,這些就需要可逆加密。
SELECT DECODE(ENCODE(‘123456′,’key_salt’),’key_salt’) ; SELECT AES_DECRYPT(AES_ENCRYPT(‘cicada’,’salt123′),’salt123′);
上述數據安全的管理,也可以基於應用系統的服務(代碼)層進行處理,相對專業的流程是從數據生成源頭處理,規避數據傳遞過程泄露,造成不必要的風險。
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hk/n/227501.html