數據庫表設計--備份記錄的表設計優化

##================================================================##

需求場景：

因爲MySQL沒有相似於SQL SERVER那樣的系統表來存放備份記錄，且大規模的MySQL服務器須要集中管理和查看。

服務器出現性能問題或複製延遲時，須要先判斷是否由數據備份引發。

##================================================================##

初版

按照需求，考慮到須要記錄的備份信息有備份服務器信息、備份開始結束時間、備份是否成功等消息，因而設計出初版表：

create table full_backup_log
(
    id bigint auto_increment primary key, ## 自增主鍵，業務無關
    host_ip varchar(50), ## 備份機IP
    host_port int, ## 備份機端口
    backup_type varchar(50), ## 備份類型，mysqldump和xtrabackup
    start_time datetime, ## 備份開始時間
    end_time datetime, ## 備份結束時間
    is_success int, ## 備份是否成功
    backup_message varchar(5000), ## 備份消息
    check_time datetime ##寫入或更新記錄的時間
);

##================================================================##

第二版

將backup_message弄得比較大， 主要是先把備份過程當中的一些信息寫進去，但仔細想一想，該表不能很好地記錄備份過程當中的每一步，將全部信息放入到backup_message列中不利於查看，因而新增一個詳細信息表：

create table full_backup_log_detail
(
    id bigint auto_increment primary key, ## 自增主鍵，業務無關
    full_backup_log_id bigint, ##關聯full_backup_log表主鍵
    host_ip varchar(50), ## 備份機IP
    host_port int, ## 備份機端口
    backup_type varchar(50), ## 備份類型，mysqldump和xtrabackup
    backup_message varchar(5000), ## 備份消息
    check_time datetime ##寫入或更新記錄的時間
);

雖然full_backup_log表中存放有備份機和備份類型數據，能夠經過full_backup_log_id關聯來獲取到，可是考慮full_backup_log_detail表數據數據日誌性數據，寫入後不會發生變化，所以經過冗餘來減小關聯，僅查詢full_backup_log_detail便可看某臺服務器的備份詳情。

 

##================================================================##

第三版

一般DBA關心每一個數據庫最後一次備份成功時間，而表full_backup_log中存有is_success字段用來標識備份成功，能夠經過如下SQL來獲取：

select t1.* from full_backup_log as t1
inner join (
select host_ip,host_port,max(id) as max_id from full_backup_log
where is_success=1
group by host_ip,host_port
) as t2 on t1.id=t2.max_id

若是full_backup_log表數據量較大時，好比存放幾千個實例的幾年數據，表中數據幾百萬上千萬時，上面查詢即便有合適索引也不能高效執行。

因爲DBA並不關心早前數據，能夠經過數據結轉來實現，但若是偶爾查詢早前數據則須要當前表和歷史表進行UNION，程序實現上還得判斷數據是否結轉，因而新增一表來存放最後一次成功備份記錄：

## full_backup_info用來存放備份機最後一次成功備份的記錄
create table full_backup_info
(
    id bigint auto_increment primary key, ## 自增主鍵，業務無關
    host_ip varchar(50), ## 備份機IP
    host_port int, ## 備份機端口
    backup_type varchar(50), ## 備份類型，mysqldump和xtrabackup
    start_time datetime, ## 備份開始時間
    end_time datetime, ## 備份結束時間
    backup_message varchar(5000), ## 備份消息
    check_time datetime ##寫入或更新記錄的時間
);

一樣數據容易來減小表關聯，雖然最後一次成功的備份記錄確定和full_backup_log表中的備份記錄對應，可是由於保存數據已經所有冗餘，就無需在表full_backup_info中增長字段與表full_backup_log進行關聯

 

##================================================================##

第四版

當備份進程過分使用CPU和IO資源致使性能問題並報警後，DBA須要第一時間判斷報警服務器是否處於備份過程當中，須要查看那些服務器正在進行備份：

方法1：經過full_backup_log表的start_time和end_time來獲取當前正在備份的服務器，須要對end_time來建索引，若是end_time默認爲NULL，則WHERE end_time is null or end_time >now, 性能很容易因OR而受影響，能夠考慮給end_time設置一個默認值如2199-01-01啥的，將查詢改成 where end_time >now

方法2：將full_backup_log表中is_success列擴展來標識備份狀態，若是1表示成功0表示失敗-1表示正在備份，查詢條件爲where is_success=-1，須要爲is_success列建索引，可是is_success列選擇性過低，而MySQL又不支持過濾索引，容易生成不高效的執行計劃。

解決辦法：

新建一個表，專門存放正在備份的服務器記錄，這樣只須要查詢該表即可以獲取到全部正在備份的服務器列表，備份成功後當即刪除該表記錄。

## full_backup_in_process用來存放正在備份的服務器信息
create table full_backup_in_process
(
    id bigint auto_increment primary key, ## 自增主鍵，業務無關
    host_ip varchar(50), ## 備份機IP
    host_port int, ## 備份機端口
    backup_type varchar(50), ## 備份類型，mysqldump和xtrabackup
    start_time datetime, ## 備份開始時間
    check_time datetime ##寫入或更新記錄的時間
);

 

##================================================================##

總結：

部分研發同事在進行設計時，隨着需求變化不停地修改表，經過在原表上新增字段來解決新需求，致使表字段過多，同一表處理不一樣需求，或經過複雜的SQL來實現，逼着DBA去優化SQL或建立一堆的低效索引，且美名其曰「業務需求」。但不少需求其實能夠曲線處理，每每優化業務需求和優化實現方式才能最終解決性能問題。

曾經有研發同事讓幫其優化SQL，發現其業務需求是對幾千萬數據進行排序分頁而後取TOP，幾十秒都沒法返回結果，建議其去除排序，被告知部分數據須要優先處理，而這部分須要優先處理的數據極少極少，最終解決辦法是將優先處理的數據分拆出來讓單獨的程序進行處理，其餘普通數據不排序查詢正常處理，完美解決。

雖然開個拖拉機，能夠拉貨，能夠耕田，也能代步，家裏沒電還能當個發電機，可是人生不能一個拖拉機就解決了吧！

##================================================================##

 依舊是妹子鎮壓帖子！

推女郎艾慄慄，拿走不謝！