這篇文章主要為大家展示了“MySQL數(shù)據(jù)庫的字段什么時候可以拆分”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學習一下“MySQL數(shù)據(jù)庫的字段什么時候可以拆分”這篇文章吧。
在數(shù)據(jù)庫的維護當中對表的垂直才分是必然的，基本上在業(yè)務剛開始準守 3NF 是明智的，當然也可以有一些反范式的設(shè)計。但是，建議還是應該在3NF的基礎(chǔ)上再酌情考慮反范式。
當遇到真的要對一些表進行拆分，那要拆那些字段嘞?下面我們就來分析一下。
在新業(yè)務上線后導致TPS突然增高，這時我們對新上的業(yè)務又不是很懂。而問題又要分析解決。
分析解決步驟
解析近期生成的binlog文件獲得是哪個表哪個字段操作的多。
這邊使用到了 吳炳錫 大神的一個工具 parsebinlog。
該工具可以解析出表的操作情況。
上面工具只能解析單個binlog文件的操作，如果要解析多個文件的可以使用 筆者的工具 pasrebinlog_stat.py。
pasrebinlog_stat.py 是對執(zhí)行parsebinlog解析完之后的數(shù)據(jù)進行的統(tǒng)計生成excel文件的工具。
具體使用方法(在github最后有一點小小的說明):https://github.com/daiguadaidai/mysql-binlog-statistic。
使用筆者的方法統(tǒng)計后會生成 5 個文件:
ll
-rw-rw-r-- 1 manager manager 58191 Sep 6 17:18 format.txt
-rw-rw-r-- 1 manager manager 100352 Sep 6 17:18 sort_by_delete.xls
-rw-rw-r-- 1 manager manager 100352 Sep 6 17:18 sort_by_insert.xls
-rw-rw-r-- 1 manager manager 100352 Sep 6 17:18 sort_by_total.xls
-rw-rw-r-- 1 manager manager 100352 Sep 6 17:18 sort_by_update.xls
如果關(guān)心update操作可以查看sort_by_update.xls 其中是按update操作次數(shù)降序排列的。
然后根據(jù)要了解的 表名 到format.txt中查看哪個字段更新平凡。
查看解析出的文件相關(guān) excel
如這邊我在sort_by_update.xls文件中看到 t1 表在定義行，說明他的總update量最多。
然后在format.txt找到 t1 表的統(tǒng)計格式如下：
Table `app_db`.`easy_channel_item`:
Type TOTAL opt: 440353
Type INSERT opt: 8049
Type DELETE opt: 1419
Type UPDATE opt: 430885
28 col : 517
23 col : 145
7 col : 379383
6 col : 46449
12 col : 2
13 col : 2
9 col : 21
8 col : 21
5 col : 4102
4 col : 3853
26 col : 3
27 col : 173
21 col : 136
24 col : 3
25 col : 116
從上可以很清楚的看到 '6 col' 和 '7 col'操作占用了大多的update操作。
通過查看數(shù)據(jù)庫表結(jié)構(gòu)可以知道這兩個字段分表是 price 和 inventory。
拆分字段
知道了哪個表的那個字段update頻繁，可以先將字段從表中剝離出單獨的表。至于需要不要開另外的庫需要看會不會對其他主要業(yè)務有影響(如：下單付款等)。如果有影響在拆到其他庫中。
拆出來的目的主要是為了讓每一個page能存儲更多的數(shù)據(jù)，并且不會讓 t1 表的數(shù)據(jù)在緩存中能保存的更長久，不會出現(xiàn)平凡的age out 顯現(xiàn)(沒有解決TPS高的問題)。
對于要提高TPS一般有兩種方法
第一種：將TPS分散，也就是需要將表進行分區(qū)到不同庫(一般這樣要考慮的東西太多。數(shù)據(jù)量不大一般不考慮)。
第二種：使用能提供更高TPS的產(chǎn)品(這邊建議 redis 是不錯的選擇)。
這邊排除第一種
使用第二種：
更具時間經(jīng)驗值：一般使用redis 能提供 TPS:3-5W 更具機器情況還有所提高。
QPS:7-10W 更具機器情況還有所提高。
對于我們的TPS的情況 3-5W TPS 的redis一般能夠勝任
這邊主要擔心的就是有關(guān) 持久化 的問題，這就是架構(gòu)上需要設(shè)計的了。
redis 自身具有持久化功能，每秒持久化一次。
更具我們 同步的情況其實同步可以忍受短時間不實時現(xiàn)象。如果出現(xiàn)redis失效(宕機或怎么的可以重啟redis重新同步所有數(shù)據(jù))。
可以搭建 redis的master-slave 或 cluster 都行這樣就能很好的解決一臺redis宕機問題。
可以根據(jù) 數(shù)據(jù)庫軟件設(shè)計的某些原理和借鑒秒殺架構(gòu)，在后臺不定期的將redis的數(shù)據(jù)同步到MySQL。
步驟可以有：
先將相關(guān)數(shù)據(jù) 格式化 的寫入到日志文件(有能力提供消息隊列更好)。
寫入日志成功之后再將數(shù)據(jù)在redis做操作。確保出問題有數(shù)據(jù)庫可查。
以上是“MySQL數(shù)據(jù)庫的字段什么時候可以拆分”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
