MySQL中修正表構造時須要留意的一些處所。本站提示廣大學習愛好者：（MySQL中修正表構造時須要留意的一些處所）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL中修正表構造時須要留意的一些處所正文
MySql 在修正表構造的時刻能夠會中止產物的正常運轉影響用戶體驗，乃至更壞的成果，喪失數據。不是一切的數據庫治理員、法式員、體系治理員都異常懂得Mysql能防止這類情形。DBA會常常碰著這類臨盆中止的情形，當進級劇本修正了運用層和數據庫層，或許缺少經歷的治理員、開辟在不是很懂得Mysql外部任務機制的情形下修正了標准文件。
本相是：
Percona MySQL 辦事器開辟團隊勉勵用戶在籌劃或許履行數據庫遷徙的時刻先和我們溝通。我們的目的是基於用戶給出的各類情形給出最好的計劃。旨在防止鎖表當用戶對異常年夜的表履行DDL，以確保運用能像平凡一樣正常運轉，同時也在盡力改良呼應時光或增長體系功效。最差的情形是確保那些經不起當機的體系在黃金生意業務時光正常運轉。
我們應用的年夜多半裝置包依然小於Mysql5.6，這須要我們一直測驗考試新的裝置情況來把數據庫遷徙形成的喪失降到最低。這能夠須要一個能“在線修正標准界說文件”的對象來進級或許修正標准文件。Mysql5.6處理這一成績的做法是經由過程削減重建表和鎖表的場景，但這個辦法不克不及籠罩一切的能夠的操作，例如當修正一列的數據類型時必定須要全表重構。Przemys?aw和 Malkowski在客歲盡量詳實的評論辯論了Mysql5.6運轉中修正界說。
關於Mysql5.6的用戶，最好的建議是回想一下數矩陣來熟習在MYSQL以外履行界說的更改，好新聞是我們很善於處理這一成績。
說真話，鎖表操作會常常被疏忽，在操作30M年夜小的表時我們更偏向於直接修正，然則30G，300G的表就要斟酌一下了。當應用率不高或許對鎖准時間請求不是很高的的體系來講直接操作或許更好。可是，我們經常會碰到一個須要立刻履行的SQL，或許由於機能成績須要緊迫增長一個索引來削減加載時光。
能否須要在體系在線期修正表界說
下面提到，在線修正表界說是任務流中的一個模塊。平日是不錯的處理計劃，但也會碰到不克不及應用的場所，例如：當某個表應用了觸發器。懂得pt-osc在我們項目中的任務進程很主要，讓我們來看一下源代碼：
[moore@localhost]$ egrep 'Step' pt-online-schema-change
# 步調 1: 創立一個新表
# 步調 2: 修正清空表. 這應當比擬快,
# Step 3: 創立觸發器來捕捉原始表的轉變 <--(鎖定元數據)
# Step 4: 復制數據.
# Step 5: 重定名表: <--(鎖定元數據
# Step 6: 更新外鍵 假如是子表.
# Step 7: 刪除舊表.
我把下面第三步到第五步高亮出來，這是鎖表能夠惹起體系停機的時光。但步調六設計外鍵更新是一個輪回的操作，是防止在更新關系的時刻隱含地重建表。有許多辦法可以確保表的完全性束縛，在pt-osc的解釋文檔中具體解釋了，在開端之前預覽你的表構造包含束縛，並曉得如何把修正表界說所形成的影響降到最低。
比來，我們告訴了一個具有高並發高事務量體系的用戶運轉pt-osc在年夜型數據表上。這件事關於他們來講很平凡，幾小時後我們的客服原告知該客戶碰到了最年夜銜接數跨越的成績。這個成績是若何發生的呢？當pt-osc運轉到步調五的時刻會測驗考試去鎖定命據偏重定名原表和隱蔽表，但是這不會在開啟事務的時刻立刻履行，是以這條線程會被排在重定名前面。這表示在用戶運用上就是體系停機。數據庫沒法開啟新的銜接而且一切的線程都被壅塞在重定名敕令以後。
5.5.3版本的解釋，當開啟一個事務時會鎖定它會用到的一切表的數據（不依附於存儲引擎），並在事務提交的時刻釋放鎖。如許做確保了在開啟事務時代不克不及修正表的界說。
久遠來看我們可以采取一些新的技巧來防止這類情形，例如non-default pt-osc的選項，換言之就是不會刪除原表把數據換到新表。這類結合離開了隱蔽表和觸發器，我們應當勉勵將重定名操作變得原子化。
校正：2.2版本的percona對象新增了一個變量–tries 和變量–set-vars 配合被安排，處理了各類pt-osc操作能夠會鎖表的情形。pt-osc (–set-vars)默許會設置以下的會話變量當銜接到數據庫辦事器的時刻。
wait_timeout=10000
innodb_lock_wait_timeout=1
lock_wait_timeout=60
當應用 –tries 我們可以顆粒化地辨別操作，測驗考試次數、在測驗考試的距離期待。這類組合可以確保pt-osc在適合的機會殺失落本身的期待會話過程，確保線程客棧的余暇，並供給給我們輪回操作來獲得治理因觸發器、重定名、修正外鍵而形成的鎖。
–tries swap_tables:5:0.5,drop_triggers:5:0.5
解釋文檔在這裡http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html#cmdoption-pt-online-schema-change–tries
它論述了即使應用了諸如pt-osc之類的對象，充足懂得你想處理的成績是很主要。上面的流程圖會贊助你當你懂得修正了MYSQL數據庫的構造的留意事項。請細心浏覽建議雖然有些圖上未標出，例如磁盤空間，IO加載等。
選擇適合的DDL操作
確保能清晰懂得在修正表構造對你的體系會發生何種影響，並選擇適合的辦法來使這類影響降到最低。有時這意味著須要將修改延期直到體系到了不常應用的時刻或許應用能在操作時代不鎖表的對象。當你表中有觸發器的時刻普通直接修正表構造。
