MySQL基礎篇(02)：從五個維度出發，審視表結構設計

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、數據場景

一、表結構簡介

任何工具類的東西都是爲了解決某個場景下的問題，好比Redis緩存系統熱點數據，ClickHouse解決海量數據的實時分析，MySQL關係型數據庫存儲結構化數據。數據的存儲則須要設計對應的表結構，清楚的表結構，有助於快速開發業務，和理解系統。表結構的設計一般從下面幾個方面考慮：業務場景、設計規範、表結構、字段屬性、數據管理。

二、用戶場景

例如存儲用戶基礎信息數據，一般都會下面幾個相關表結構：用戶信息表、單點登陸表、狀態管理表、支付帳戶表等。

• 用戶信息表

存儲用戶三要素相關信息：姓名，手機號，身份證，登陸密碼，郵箱等。

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='用戶錢包';

2、設計規範

一、涉及模塊

經過上面幾個表設計的案例，能夠看到表設計關聯到數據庫的各個方面知識：數據類型，索引，編碼，存儲引擎等。表設計是一個很大的命題，不過也遵循一個基本規範：三範式。

二、三範式

• 基礎概念

一範式

表的列的具備原子性,不可再分解，即列的信息，不能分解,關係型數據庫MySQL、Oracle等自動的知足。

二範式

每一個事實的數據記錄只會出現一次, 不會冗餘, 一般設計一個主鍵來實現。

三範式

要求一個表中不包含已經存在於其它表的非主鍵信息，例如部門和員工的信息，員工表包含部門表的主鍵ID，則能夠關聯獲取相關信息，不必在員工表保存相關信息。

• 優缺點對比

範式化設計

範式化結構設計一般更新快，由於冗餘數據較少，表結構輕巧，也更好的寫入內存中。可是查詢起來涉及到關聯，代價很是高，很是損耗查詢性能。

反範式化設計

全部的數據都在一張表中，避免關聯查詢，索引的有效性更高，可是數據的冗餘性極高。

• 建議結論

上述的兩種設計方式在實際開發中都是不存在的，在實際開發中都是混合使用。好比彙總統計，緩存數據，都會基於反範式化的設計。

3、字段屬性

合適的字段類型對於高性能來講很是重要，基本原則以下：簡單的類型佔用資源更少；在能夠正確存儲數據的狀況下，選最小的數據類型。

一、數據類型選擇

• 整數類型

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根據數據類型範圍合理選擇便可。

• 實數類型

FLOAT、DOUBLE、DECIMAL，建議資金貨幣相關類型使用高精度DECIMAL存儲，或者把數據成倍擴大爲整數，採用BIGINT存儲，不過處理相對麻煩。

• 字符類型

CHAR、VARCHAR，長度不肯定建議採用VARCHAR存儲，不過VARCHAR類型須要額外開銷記錄字符串長度。CHAR適合存儲短字符，或者定長字符串，例如MD5的加密結構。

• 時間類型

DATETIME、TIMESTAMP，DATETIME保存大範圍的值，精度秒。TIMESTAMP以時間戳的格式，範圍相對較小，效率也相對較高，因此一般狀況建議使用。

MySQL的字段類型有不少種，能夠根據數據特性選擇合適的，這裏只描述常見的幾種類型。

二、基礎用法操做

• 數據類型

修改字段類型

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 ;

4、表結構管理

一、查看結構

DESC ms_user_status ;
SHOW CREATE TABLE ms_user_status ;

二、字段結構

• 添加字段

ALTER TABLE ms_user_status 
ADD `delete_time` datetime DEFAULT NULL COMMENT '刪除時間' ;

• 刪除字段

ALTER TABLE ms_user_status DROP COLUMN delete_time ;

三、修改表名

ALTER TABLE ms_user_center RENAME ms_user_info ;

四、存儲引擎

• 存儲引擎

SELECT VERSION() ; SHOW ENGINES ;

MySQL 5.6 支持的存儲引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。通常默認使用InnoDB，支持事務管理。該模塊MySQL核心，後續詳解。

• 修改引擎

數據量大的場景下，存儲引擎修改是一個難度極大的操做，容易會致使表的特性變更，引發各類後續反應，後續會詳說。

ALTER TABLE ms_user_sso ENGINE = MyISAM ;

五、修改編碼

表字符集默認使用utf8，通用，無亂碼風險，漢字3字節，英文1字節，utf8mb4是utf8的超集，有存儲4字節例如表情符號時使用。

• 查看編碼

SHOW VARIABLES LIKE 'character%';

• 修改編碼

ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4;

5、數據管理

一、增刪改查

添加數據

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也是清空表數據，可是佔用的資源相對較少。

二、數據安全

• 不可逆加密

這類加密算法，多用來作數據驗證操做，好比常見的密碼驗證。

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');

上述數據安全的管理，也能夠基於應用系統的服務(代碼)層進行處理，相對專業的流程是從數據生成源頭處理，規避數據傳遞過程泄露，形成沒必要要的風險。

6、源代碼地址

GitHub·地址
https://github.com/cicadasmile/mysql-data-base
GitEE·地址
https://gitee.com/cicadasmile/mysql-data-base