共計 2099 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章主要為大家展示了“MySQL 數據庫的字段什么時候可以拆分”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“MySQL 數據庫的字段什么時候可以拆分”這篇文章吧。
在數據庫的維護當中對表的垂直才分是必然的，基本上在業務剛開始準守 3NF 是明智的，當然也可以有一些反范式的設計。但是，建議還是應該在 3NF 的基礎上再酌情考慮反范式。
當遇到真的要對一些表進行拆分，那要拆那些字段嘞? 下面我們就來分析一下。
在新業務上線后導致 TPS 突然增高，這時我們對新上的業務又不是很懂。而問題又要分析解決。
分析解決步驟
解析近期生成的 binlog 文件獲得是哪個表哪個字段操作的多。
這邊使用到了 吳炳錫 大神的一個工具 parsebinlog。
該工具可以解析出表的操作情況。
上面工具只能解析單個 binlog 文件的操作，如果要解析多個文件的可以使用 筆者的工具 pasrebinlog_stat.py。
pasrebinlog_stat.py 是對執行 parsebinlog 解析完之后的數據進行的統計生成 excel 文件的工具。
具體使用方法 (在 github 最后有一點小小的說明):https://github.com/daiguadaidai/mysql-binlog-statistic。
使用筆者的方法統計后會生成 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
如果關心 update 操作可以查看 sort_by_update.xls 其中是按 update 操作次數降序排列的。
然后根據要了解的 表名 到 format.txt 中查看哪個字段更新平凡。
查看解析出的文件相關 excel
如這邊我在 sort_by_update.xls 文件中看到 t1 表在定義行，說明他的總 update 量最多。
然后在 format.txt 找到 t1 表的統計格式如下：
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 操作。
通過查看數據庫表結構可以知道這兩個字段分表是 price 和 inventory。
拆分字段
知道了哪個表的那個字段 update 頻繁，可以先將字段從表中剝離出單獨的表。至于需要不要開另外的庫需要看會不會對其他主要業務有影響 (如：下單付款等)。如果有影響在拆到其他庫中。
拆出來的目的主要是為了讓每一個 page 能存儲更多的數據，并且不會讓 t1 表的數據在緩存中能保存的更長久，不會出現平凡的 age out 顯現 (沒有解決 TPS 高的問題)。
對于要提高 TPS 一般有兩種方法
第一種：將 TPS 分散，也就是需要將表進行分區到不同庫 (一般這樣要考慮的東西太多。數據量不大一般不考慮)。
第二種：使用能提供更高 TPS 的產品 (這邊建議 redis 是不錯的選擇)。
這邊排除第一種
使用第二種：
更具時間經驗值：一般使用 redis 能提供 TPS:3-5W 更具機器情況還有所提高。
QPS:7-10W 更具機器情況還有所提高。
對于我們的 TPS 的情況 3-5W TPS 的 redis 一般能夠勝任
這邊主要擔心的就是有關 持久化 的問題，這就是架構上需要設計的了。
redis 自身具有持久化功能，每秒持久化一次。
更具我們 同步的情況其實同步可以忍受短時間不實時現象。如果出現 redis 失效 (宕機或怎么的可以重啟 redis 重新同步所有數據)。
可以搭建 redis 的 master-slave 或 cluster 都行這樣就能很好的解決一臺 redis 宕機問題。
可以根據 數據庫軟件設計的某些原理和借鑒秒殺架構，在后臺不定期的將 redis 的數據同步到 MySQL。
步驟可以有：
先將相關數據 格式化 的寫入到日志文件 (有能力提供消息隊列更好)。
寫入日志成功之后再將數據在 redis 做操作。確保出問題有數據庫可查。
以上是“MySQL 數據庫的字段什么時候可以拆分”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！
