MySQL數(shù)據(jù)庫(kù)的字段什么時(shí)候可以拆分

這篇文章主要為大家展示了“MySQL數(shù)據(jù)庫(kù)的字段什么時(shí)候可以拆分”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“MySQL數(shù)據(jù)庫(kù)的字段什么時(shí)候可以拆分”這篇文章吧。

　　在數(shù)據(jù)庫(kù)的維護(hù)當(dāng)中對(duì)表的垂直才分是必然的，基本上在業(yè)務(wù)剛開(kāi)始準(zhǔn)守 3NF 是明智的，當(dāng)然也可以有一些反范式的設(shè)計(jì)。但是，建議還是應(yīng)該在3NF的基礎(chǔ)上再酌情考慮反范式。

　　當(dāng)遇到真的要對(duì)一些表進(jìn)行拆分，那要拆那些字段嘞?下面我們就來(lái)分析一下。

　　在新業(yè)務(wù)上線后導(dǎo)致TPS突然增高，這時(shí)我們對(duì)新上的業(yè)務(wù)又不是很懂。而問(wèn)題又要分析解決。

　　分析解決步驟

　　解析近期生成的binlog文件獲得是哪個(gè)表哪個(gè)字段操作的多。

　　這邊使用到了 吳炳錫 大神的一個(gè)工具 parsebinlog。

　　該工具可以解析出表的操作情況。

　　上面工具只能解析單個(gè)binlog文件的操作，如果要解析多個(gè)文件的可以使用 筆者的工具 pasrebinlog_stat.py。

　　pasrebinlog_stat.py 是對(duì)執(zhí)行parsebinlog解析完之后的數(shù)據(jù)進(jìn)行的統(tǒng)計(jì)生成excel文件的工具。

　　具體使用方法(在github最后有一點(diǎn)小小的說(shuō)明):https://github.com/daiguadaidai/mysql-binlog-statistic。

　　使用筆者的方法統(tǒng)計(jì)后會(huì)生成 5 個(gè)文件:

　　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中查看哪個(gè)字段更新平凡。

　　查看解析出的文件相關(guān) excel

　　如這邊我在sort_by_update.xls文件中看到 t1 表在定義行，說(shuō)明他的總update量最多。

　　然后在format.txt找到 t1 表的統(tǒng)計(jì)格式如下：

　　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操作。

　　通過(guò)查看數(shù)據(jù)庫(kù)表結(jié)構(gòu)可以知道這兩個(gè)字段分表是 price 和 inventory。

　　拆分字段

　　知道了哪個(gè)表的那個(gè)字段update頻繁，可以先將字段從表中剝離出單獨(dú)的表。至于需要不要開(kāi)另外的庫(kù)需要看會(huì)不會(huì)對(duì)其他主要業(yè)務(wù)有影響(如：下單付款等)。如果有影響在拆到其他庫(kù)中。

　　拆出來(lái)的目的主要是為了讓每一個(gè)page能存儲(chǔ)更多的數(shù)據(jù)，并且不會(huì)讓 t1 表的數(shù)據(jù)在緩存中能保存的更長(zhǎng)久，不會(huì)出現(xiàn)平凡的age out 顯現(xiàn)(沒(méi)有解決TPS高的問(wèn)題)。

　　對(duì)于要提高TPS一般有兩種方法

　　第一種：將TPS分散，也就是需要將表進(jìn)行分區(qū)到不同庫(kù)(一般這樣要考慮的東西太多。數(shù)據(jù)量不大一般不考慮)。

　　第二種：使用能提供更高TPS的產(chǎn)品(這邊建議 redis 是不錯(cuò)的選擇)。

　　這邊排除第一種

　　使用第二種：

　　更具時(shí)間經(jīng)驗(yàn)值：一般使用redis 能提供 TPS:3-5W 更具機(jī)器情況還有所提高。

　　QPS:7-10W 更具機(jī)器情況還有所提高。

　　對(duì)于我們的TPS的情況 3-5W TPS 的redis一般能夠勝任

　　這邊主要擔(dān)心的就是有關(guān) 持久化 的問(wèn)題，這就是架構(gòu)上需要設(shè)計(jì)的了。

　　redis 自身具有持久化功能，每秒持久化一次。

　　更具我們 同步的情況其實(shí)同步可以忍受短時(shí)間不實(shí)時(shí)現(xiàn)象。如果出現(xiàn)redis失效(宕機(jī)或怎么的可以重啟redis重新同步所有數(shù)據(jù))。

　　可以搭建 redis的master-slave 或 cluster 都行這樣就能很好的解決一臺(tái)redis宕機(jī)問(wèn)題。

　　可以根據(jù) 數(shù)據(jù)庫(kù)軟件設(shè)計(jì)的某些原理和借鑒秒殺架構(gòu)，在后臺(tái)不定期的將redis的數(shù)據(jù)同步到MySQL。

　　步驟可以有：

　　先將相關(guān)數(shù)據(jù) 格式化 的寫(xiě)入到日志文件(有能力提供消息隊(duì)列更好)。

　　寫(xiě)入日志成功之后再將數(shù)據(jù)在redis做操作。確保出問(wèn)題有數(shù)據(jù)庫(kù)可查。

以上是“MySQL數(shù)據(jù)庫(kù)的字段什么時(shí)候可以拆分”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！