91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

MySQL數據庫的字段什么時候可以拆分

發布時間:2022-01-14 15:53:49 來源:億速云 閱讀:195 作者:小新 欄目:數據庫

這篇文章主要為大家展示了“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數據庫的字段什么時候可以拆分”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

张家口市| 常熟市| 寿宁县| 中江县| 安陆市| 日照市| 灯塔市| 晋宁县| 河西区| 民丰县| 穆棱市| 巩义市| 托克托县| 梁平县| 阜新| 建平县| 扬中市| 双牌县| 尖扎县| 商洛市| 镇宁| 玛多县| 高陵县| 大方县| 商南县| 涪陵区| 普宁市| 南岸区| 霍州市| 嘉峪关市| 玛曲县| 广汉市| 扬州市| 富平县| 武川县| 华蓥市| 驻马店市| 江山市| 金阳县| 淮北市| 洪湖市|