相對來說,什麼情況下的資料庫表能夠稱為「大表」呢?
大表對查詢的影響
大表對ddl操作的影響1、建立索引需要很長時間
風險:
mysql版本 < 5.5 建立索引會鎖表
mysql版本 >= 5.5 雖然不會鎖表但會引起主從延遲
2、修改表結構需要長時間鎖表
風險:
會造成長時間的主從延遲
影響正常的資料操作
1、分庫分表把一張大表分成多個小表難點:
分表主鍵的選擇
分表後跨分割槽資料的查詢和統計
2、大表的歷史資料歸檔優點:
減少對前後端業務的影響
難點:
歸檔時間點的選擇
如何進行歸檔的操作
事務要求符合:原子性、一致性、隔離性、永續性
事務的原子性乙個事務必須被視為不可分離的最小工作單位,整個事務中的所有操作要麼全部提交成功,要麼全部失敗,對於乙個事務來說,不可能只執行其中的一部分操作。
eg:
1、檢查理財賬戶中的餘額是否高於2000元
2、從理財賬戶的餘額中減去2000元
3、在活動存款賬戶上增加2000元
整個事務中的所有操作要麼全部提交成功,要麼全部失敗回滾。
事務的一致性一致性是指事務將資料庫從一種一致性狀態轉換到另外一種一致性狀態,在事務開始之前和事務結束後資料庫中資料的完整性沒有被破壞。
事務的隔離性隔離性要求乙個事務對資料庫中資料的修改,在未提交完成之前對於其他事務是不可見的。
sql標準中定義的四種各類級別(隔離性由低到高)(併發性由高到低)
未提交讀(read uncommited)
已提交讀(read commited)
可重複讀(repeatable read)
可序列化(serializable)
事務的永續性一旦事務提交,則其所做的修改就會永遠儲存到資料庫中,此時即使系統崩潰,已經提交的修改資料也不會丟失。
執行的時間比較長,操作的資料比較多的事務
風險:
鎖定太多的資料,造成大量的阻塞和鎖超時
回滾所需要的時間比較長
執行時間長,容易造成主從延遲
MySQL 事務併發帶來的問題與事務隔離機制
一 前言 mysql從5.5.8開始,innodb就是預設的儲存引擎,innodb最大的特點是 支援事務 支援行級鎖。既然支援事務,那麼就會有處理併發事務帶來的問題 更新丟失 髒讀 不可重複讀 幻讀。相應的為了解決這四個問題,就產生了事務隔離級別 讀未提交 read uncommitted 讀已提交...
Mysql資料庫的四大事務性
1 原子性 atomicity 原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。2 一致性 consistency 一致性是指事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態,也就是說乙個事務執行...
MySQL事務表與非事務表的優缺點
事務表 tst 即儲存引擎型別支援事務處理的表 在mysql中只有innodb和bdb儲存引擎支援事務處理 其他儲存引擎不支援事務處理。而且mysql 5.1以上版本不再支援bdb儲存引擎,所以事務處理我們用得最多的就數innodb儲存引擎了。mysql事務表支援將多條sql語句當作同一任務統一處理...