您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“MySQL數據庫的字段什么時候可以拆分”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“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數據庫的字段什么時候可以拆分”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。