【MYSQL】大表與大事務帶來的問題

前言

相對來講，什麼狀況下的數據庫表可以稱爲「大表」呢？

• 當一個表的數據超過千萬行的時候，就會對數據庫形成影響
• 當表數據文件巨大，表數據文件超過10G（數據值相對硬件而言）

大表的影響

大表對查詢的影響

慢查詢：很難在必定的時間內過濾出所須要的數據
（Eg：顯示訂單、來源少、區分度底、大量磁盤IO、下降磁盤效率、慢查詢）

大表對DDL操做的影響

一、創建索引須要很長時間

風險：

MYSQL版本 < 5.5 創建索引會鎖表
MYSQL版本 >= 5.5 雖然不會鎖表但會引發主從延遲

二、修改表結構須要長時間鎖表

風險：

會形成長時間的主從延遲
影響正常的數據操做

如何處理數據庫中的大表

一、分庫分表把一張大表分紅多個小表

難點：

分表主鍵的選擇
分表後跨分區數據的查詢和統計

二、大表的歷史數據歸檔

優勢：

減小對先後端業務的影響

難點：

歸檔時間點的選擇
如何進行歸檔的操做

什麼是事務？

• 事務是數據庫系統區別於其餘一切文件系統的重要特性之一
• 事務是一組具備原子性的SQL語句，或是一個獨立的工做單元

事務要求符合：原子性、一致性、隔離性、持久性

事務的原子性

一個事務必須被視爲不可分離的最小工做單位，整個事務中的全部操做要麼所有提交成功，要麼所有失敗，對於一個事務來講，不可能只執行其中的一部分操做。

Eg：
一、檢查理財帳戶中的餘額是否高於2000元
二、從理財帳戶的餘額中減去2000元
三、在活動存款帳戶上增長2000元

整個事務中的全部操做要麼所有提交成功，要麼所有失敗回滾。

事務的一致性

一致性是指事務將數據庫從一種一致性狀態轉換到另一種一致性狀態，在事務開始以前和事務結束後數據庫中數據的完整性沒有被破壞。

事務的隔離性

隔離性要求一個事務對數據庫中數據的修改，在未提交完成以前對於其餘事務是不可見的。

SQL標準中定義的四種各種級別（隔離性由低到高）（併發性由高到低）

未提交讀（READ UNCOMMITED）
已提交讀（READ COMMITED）
可重複讀（REPEATABLE READ）
可串行化（SERIALIZABLE）

事務的持久性

一旦事務提交，則其所作的修改就會永遠保存到數據庫中，此時即便系統崩潰，已經提交的修改數據也不會丟失。

什麼是大事務？

運行的時間比較長，操做的數據比較多的事務

風險：

鎖定太多的數據，形成大量的阻塞和鎖超時
回滾所須要的時間比較長
執行時間長，容易形成主從延遲

如何處理大事務？

• 避免一次處理太多的數據
• 移出沒必要要在事務中的SELECT操做

---

若是本文對你有所幫助，歡迎關注我的公衆號，謝謝。