維護mysql資料庫表,MySQL維護

本文目錄一覽：

• 1、如何處理mysql中表損壞問題
• 2、mysql 資料庫表間關係圖怎麼查看?
• 3、講解MySQL資料庫表如何修復
• 4、資料庫（mysql）關鍵知識
• 5、如何對MySQL資料庫日誌文件進行維護
• 6、MySQL資料庫表被鎖、解鎖，刪除事務

如何處理mysql中表損壞問題

5.9.4. 表維護和崩潰恢復

後面幾節討論如何使用myisamchk來檢查或維護MyISAM表(對應.MYI和.MYD文件的表)。

你可以使用myisamchk實用程序來獲得有關你的資料庫表的信息或檢查、修復、優化他們。下列小節描述如何調用myisamchk（包括它的選項的描述），如何建立表的維護計劃，以及如何使用myisamchk執行各種功能。

儘管用myisamchk修復表很安全，在修復(或任何可以大量更改表的維護操作)之前先進行備份也是很好的習慣

影響索引的myisamchk操作會使ULLTEXT索引用full-text參數重建，不再與MySQL伺服器使用的值兼容。要想避免，請閱讀5.9.5.1節，「用於myisamchk的一般選項」的說明。

在許多情況下，你會發現使用SQL語句實現MyISAM表的維護比執行myisamchk操作要容易地多：

· 要想檢查或維護MyISAM表，使用CHECK TABLE或REPAIR TABLE。

· 要想優化MyISAM表，使用OPTIMIZE TABLE。

· 要想分析MyISAM表，使用ANALYZE TABLE。

可以直接這些語句，或使用mysqlcheck客戶端程序，可以提供命令行介面。

這些語句比myisamchk有利的地方是伺服器可以做任何工作。使用myisamchk，你必須確保伺服器在同一時間不使用表。否則，myisamchk和伺服器之間會出現不期望的相互干涉。

5.9.5. myisamchk：MyISAM表維護實用工具

5.9.5.1. 用於myisamchk的一般選項

5.9.5.2. 用於myisamchk的檢查選項

5.9.5.3. myisamchk的修複選項

5.9.5.4. 用於myisamchk的其它選項

5.9.5.5. myisamchk內存使用

5.9.5.6. 將myisamchk用於崩潰恢復

5.9.5.7. 如何檢查MyISAM表的錯誤

5.9.5.8. 如何修復表

5.9.5.9. 表優化

可以使用myisamchk實用程序來獲得有關資料庫表的信息或檢查、修復、優化他們。myisamchk適用MyISAM表(對應.MYI和.MYD文件的表)。

調用myisamchk的方法：

shell myisamchk [options] tbl_name …

options指定你想讓myisamchk做什麼。在後面描述它們。還可以通過調用myisamchk –help得到選項列表。

tbl_name是你想要檢查或修復的資料庫表。如果你不在資料庫目錄的某處運行myisamchk，你必須指定資料庫目錄的路徑，因為myisamchk不知道你的資料庫位於哪兒。實際上，myisamchk不在乎你正在操作的文件是否位於一個資料庫目錄；你可以將對應於資料庫表的文件拷貝到別處並且在那裡執行恢復操作。

如果你願意，可以用myisamchk命令行命名幾個表。還可以通過命名索引文件(用「 .MYI」後綴)來指定一個表。它允許你通過使用模式「*.MYI」指定在一個目錄所有的表。例如，如果你在資料庫目錄，可以這樣在目錄下檢查所有的MyISAM表：

shell myisamchk *.MYI

如果你不在資料庫目錄下，可通過指定到目錄的路徑檢查所有在那裡的表：

shell myisamchk /path/to/database_dir/*.MYI

你甚至可以通過為MySQL數據目錄的路徑指定一個通配符來檢查所有的資料庫中的所有表：

shell myisamchk /path/to/datadir/*/*.MYI

推薦的快速檢查所有MyISAM表的方式是：

shell myisamchk –silent –fast /path/to/datadir/*/*.MYI

如果你想要檢查所有MyISAM表並修復任何破壞的表，可以使用下面的命令：

shell myisamchk –silent –force –fast –update-state \

-O key_buffer=64M -O sort_buffer=64M \

-O read_buffer=1M -O write_buffer=1M \

/path/to/datadir/*/*.MYI

該命令假定你有大於64MB的自由內存。關於用myisamchk分配內存的詳細信息，參見5.9.5.5節，「myisamchk內存使用」。

當你運行myisamchk時，必須確保其它程序不使用表。否則，當你運行myisamchk時，會顯示下面的錯誤消息：

warning: clients are using or haven’t closed the table properly

這說明你正嘗試檢查正被另一個還沒有關閉文件或已經終止而沒有正確地關閉文件的程序(例如mysqld伺服器)更新的表。

如果mysqld正在運行，你必須通過FLUSH TABLES強制清空仍然在內存中的任何錶修改。當你運行myisamchk時，必須確保其它程序不使用表。避免該問題的最容易的方法是使用CHECK TABLE而不用myisamchk來檢查表。

5.9.5.1. 用於myisamchk的一般選項

本節描述的選項可以用於用myisamchk執行的任何類型的表維護操作。本節後面的章節中描述的選項只適合具體操作，例如檢查或修復表。

· –help，-?

顯示幫助消息並退出。

· –debug=debug_options, -# debug_options

輸出調試記錄文件。debug_options字元串經常是’d:t:o,filename’。

· –silent，-s

沉默模式。僅當發生錯誤時寫輸出。你能使用-s兩次(-ss)使myisamchk沉默。

· –verbose，-v

冗長模式。列印更多的信息。這能與-d和-e一起使用。為了更冗長，使用-v多次(-vv, -vvv)！

· –version, -V

顯示版本信息並退出。

· –wait, -w

如果表被鎖定，不是提示錯誤終止，而是在繼續前等待到表被解鎖。請注意如果用–skip-external-locking選項運行mysqld，只能用另一個myisamchk命令鎖定表。

還可以通過–var_name=value選項設置下面的變數：

變數

默認值

decode_bits

9

ft_max_word_len

取決於版本

ft_min_word_len

4

ft_stopword_file

內建列表

key_buffer_size

523264

myisam_block_size

1024

read_buffer_size

262136

sort_buffer_size

2097144

sort_key_blocks

16

stats_method

nulls_unequal

write_buffer_size

262136

可以用myisamchk –help檢查myisamchk變數及其 默認值：

當用排序鍵值修復鍵值時使用sort_buffer_size，使用–recover時這是很普通的情況。

當用–extend-check檢查表或通過一行一行地將鍵值插入表中(如同普通插入)來修改鍵值時使用Key_buffer_size。在以下情況通過鍵值緩衝區進行修復：

· 使用–safe-recover。

· 當直接創建鍵值文件時，需要對鍵值排序的臨時文件有兩倍大。通常是當CHAR、VARCHAR、或TEXT列的鍵值較大的情況，因為排序操作在處理過程中需要保存全部鍵值。如果你有大量臨時空間，可以通過排序強制使用myisamchk來修復，可以使用–sort-recover選項。

通過鍵值緩衝區的修復佔用的硬碟空間比使用排序么少，但是要慢。

如果想要快速修復，將key_buffer_size和sort_buffer_size變數設置到大約可用內存的25%。可以將兩個變數設置為較大的值，因為一個時間只使用一個變數。

myisam_block_size是用於索引塊的內存大小。

stats_method影響當給定–analyze選項時，如何為索引統計搜集處理NULL值。它如同myisam_stats_method系統變數。詳細信息參見5.3.3節，「伺服器系統變數」和7.4.7節，「MyISAM索引統計集合」的myisam_stats_method的描述。

ft_min_word_len和ft_max_word_len表示FULLTEXT索引的最小和最大字長。ft_stopword_file為停止字文件的文件名。需要在以下環境中對其進行設置。

如果你使用myisamchk來修改表索引(例如修復或分析)，使用最小和最大字長和停止字文件的 默認全文參數值（除非你另外指定）重建FULLTEXT索引。這樣會導致查詢失敗。

出現這些問題是因為只有伺服器知道這些參數。它們沒有保存在MyISAM索引文件中。如果你修改了伺服器中的最小或最大字長或停止字文件，要避免該問題，為用於mysqld的myisamchk指定相同的ft_min_word_len，ft_max_word_len和ft_stopword_file值。例如，如果你將最小字長設置為3,可以這樣使用myisamchk來修復表：

shell myisamchk –recover –ft_min_word_len=3 tbl_name.MYI

要想確保myisamchk和伺服器使用相同的全文

mysql 資料庫表間關係圖怎麼查看?

mysql資料庫表間的關係圖可以通過navicat查看：

第一步：下載navicat打開；

第二步：點擊navicat界面最右下角標註的按鈕即可查看關係圖。

最新的MySQL Workbench已經完全包含了資料庫建模與設計、資料庫SQL開發和資料庫管理與維護等功能。

Mysql資料庫—–表

sh.qihoo.com 2018-04-07 08:20

1、定義: 表（table）是資料庫最基本的組成單元，資料庫是用來存儲數據的，資料庫中有很多表，每一個表都是一個獨立的單元，表也是一個結構化的文件，由行和列組成，行稱為數據或記錄，列稱為欄位，欄位又包含：欄位名稱、欄位類型、長度、約束。

2、創建表

（1）、語法格式:create table 表名稱(欄位名 類型(長度) 約束)；

（2）、MySQL常用數據類型

VARCHAR：可變長度字元串(VARCH AR(3)表示存儲的數據長度丌能超過3個字元長度)

CHAR：定長字元串(CHAR(3) 表示存儲的數據長度丌能超過3個字元長度)

INT：整數型（INT(3)表示最大可以存儲999）

BIGINT：長整型（對應java程序中的long類型）

FLOAT：浮點型單精度（FLOAT(7,2)表示7個有效數字，2個有效小數位）

DOUBLE：浮點型雙精度（DOUBLE(7,2)表示7個有效數字，2個有效小數位）

DATE：日期類型（ 實際開發中，常用字元串代替日期類型）

BLOB：二進位大對象 Binary Large Object（專門存儲圖片、視頻、聲音等數據）

CLOB：字元型大對象 Character Large Object（ 可存儲超大文本，可存儲4G+字元串）

VARCHAR與CHAR對比：

都是字元串

VARCHAR比較智能，可以根據實際的數據長度分配空間，比較節省空間；但在分配的時候需要相關判斷，效率低。

CHAR不需要勱態分配空間，所以執行效率高，但是可能會導致空間浪費

若欄位中的數據不具備伸縮性，建議採用CHAR類型存儲

若欄位中的數據具備很強的伸縮性，建議採用VARCHAR類型存儲

講解MySQL資料庫表如何修復

一張損壞的表的癥狀通常是查詢意外中斷並且你能看到例如這些錯誤：◆ 「tbl_name.frm」被鎖定不能改變。◆ 不能找到文件「tbl_name.MYI」(Errcode ：### )。◆ 從表處理器的得到錯誤###(此時，錯誤135是一個例外)。◆ 意外的文件結束。◆ 記錄文件被毀壞。在這些情況下，你必須修復表。表的修復是一項非常困難的工作，很多情況下令人束手無策。然而，有一些常規的知道思想和過程，可以遵循它們來增加修正表的機會。通常，開始是可以用最快的修復方法，看看能否袖珍故障。如果發現不成功，可以逐步升級到更徹底的但更慢的修復方法。如果仍舊難以修復，就應該從備份中恢復了。在上一章已經詳細介紹了這一部分內容。簡單安全的修復為了修復一個表執行下列步驟：◆ 首先，用–recover,-r選項修正表，並且用–quick，-q選項，來只根據索引文件的內容進行恢復。這樣不接觸數據文件來修復索引文件。(-r意味著「恢復模式」)myisamchk -r -q tbl_nameisamchk -r -q tbl_name◆ 如果問題仍舊存在，則忽略–quick選項，允許修復程序修改數據文件，因為這可能存在問題。下面的命令將從數據文件中刪除不正確的記錄和已被刪除的記錄並重建索引文件：myisamchk -r tbl_nameisamchk -r tbl_name◆ 如果前面的步驟失敗，使用。安全恢復模式使用一個老的恢復方法，處理常規恢復模式不行的少數情況(但是更慢)。myisamchk –safe-recover tbl_nameisamchk –safe-recover tbl_name困難的修理如果在索引文件的第一個16K塊被破壞，或包含不正確的信息，或如果索引文件丟失，你只應該到這個階段 。在這種情況下，創建一個新的索引文件是必要的。按如下這樣的步驟做：◆ 定位到包含崩潰表的資料庫目錄中◆ 把數據文件移更安全的地方。

資料庫（mysql）關鍵知識

Mysql是目前互聯網使用最廣的關係資料庫，關係資料庫的本質是將問題分解為多個分類然後通過關係來查詢。 一個經典的問題是用戶借書，三張表，一個用戶，一個書，一個借書的關係表。當需要查詢某個用戶借書情況或者是書被那些人借了，就用關係查詢來實現。

關係資料庫範式

來自英文Normal form，簡稱NF。要想設計—個好的關係，必須使關係滿足一定的約束條件，滿足這些規範的資料庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。總共有六種範式：第一範式（1NF）、第二範式（2NF）、 第三範式 （3NF）、巴斯-科德範式（BCNF）、 第四範式 (4NF）和 第五範式 （5NF，又稱完美範式）。

1NF是指資料庫表的每一列都是不可分割的原子數據項。2NF必須滿足1NF，要求資料庫表中的每行記錄必須可以被唯一地區分。3NF在2NF基礎上，任何非主 屬性 不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）。BCNF是在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）， 滿足BCNF不再會有任何由於函數依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。4NF的定義很簡單：已經是BC範式，並且不包含多值依賴關係。5NF處理的是無損連接問題，這個範式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵範式試圖定義一個終極範式，該範式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。

Catalog和Schema

是資料庫對象命名空間中的層次，主要用來解決命名衝突的問題。從概念上說，一個資料庫系統包含多個Catalog，每個Catalog又包含多個Schema，而每個Schema又包含多個資料庫對象（表、視圖、欄位等）。但是Mysql的資料庫名就是Schema，不支持Catalog。

Mysql的資料庫引擎主要有兩種MyISAM和InnoDB，MyISAM支持全文檢索，InnoDB支持事務。

SQL中的通配符『%』代表任意字元出現任意次數。『_』代表任意字元出現一次。SQL與正則表達式結合查詢一般用在WHERE table_name REGEXP ‘^12.34’。子查詢是從裡到外執行。

資料庫聯結（join）涉及到外鍵，外鍵是指一個表的列是另一個表的主鍵，那麼它就是外鍵。笛卡爾積聯結（不指定聯結條件時）生成的記錄條目是單純的第一個表的行乘以第二個表的列數。用得最多的是等值聯結也叫內部聯結。

高級聯結還有自連接，是指查詢中的兩張表是同一張表，它通常作為外部語句用來代替從相同表中檢索數據時使用的子查詢。自然聯結使每個列只返回一次。外部聯結是指聯結包含了那些在相關表中沒有關聯行的行。例如列出所有產品及其訂購數量，包括沒有人訂購的產品。LEFT OUTER JOIN指選擇左邊表的所有行。

組合查詢是指採用UNION等將兩個查詢結果取並集。

視圖是查看存儲在別處的數據的一種工具，它本身並不包含數據，因此表的數據修改了，視圖返回的數據也將隨之修改，因此如果使用了複雜或嵌套視圖會對性能有較大的影響。視圖的作用之一是隱藏複雜的SQL通常會涉及到聯結查詢。

存儲過程類似於批處理，包含了一條或多條SQL語句。語法：

CREATE PROCEDURE name（）

BEGIN

SQL

END

————————-

CALL name（）//來調用存儲過程

游標有DECLARE定義，游標與存儲過程是綁定的，存儲過程處理完成，游標就會消失。游標被打開後可以使用FETCH語句訪問每一行。

觸發器是在某個時間發生時自動執行某條SQL語句。語法：

CREATE TRIGGER name AFTER INSERT ON talbe_name FOR EACH ROW

事務處理可以維護資料庫的完整性，保證批量的操作要麼完全執行，要麼完全不執行。包括事務、回退、提交、保留點幾個關鍵術語。ROLLBACK只能在一個事務處理內使用。他不能回退CREATE和DROP操作。使用COMMIT保證事務提交。複雜的事務處理需要部分提交或回退，因此我們需要使用保留點SAVEPOINT。可以使用ROLLBACK TO savepoint_name。保留點越多越好。保留點在事務執行完成後自動釋放。

如何對MySQL資料庫日誌文件進行維護

用下列方法可以強制伺服器啟用新的更新日誌：

◆ mysqladmin flush-logs

你一般需要在命令行提供使用的資料庫用戶：

mysqladmin –u root –p flush-logs

◆ mysqladmin refresh

你一般需要在命令行提供使用的資料庫用戶：

mysqladmin –u root –p refresh

如果你正在使用MySQL 3.21或更早的版本，你必須使用mysqladmin refresh。

◆ SQL命令

FLUSH LOGS

◆ 重啟伺服器

上述方法都具有這樣的功能：

關閉並且再打開標準和更新記錄文件。如果你指定了一個沒有擴展名的更新記錄文件，新的更新記錄文件的擴展數字將相對先前的文件加1。

mysqlFLUSH LOGS;

如何使用新的常規日誌

用上面的方法同樣可以強制更新常規日誌。

要準備備份常規日誌，其步驟可能複雜一些：

$ cd mysql-data-directory$ mv mysql.log mysql.old$ mysqladmin flush-tables

MySQL資料庫表被鎖、解鎖，刪除事務

在程序員的職業生涯中，總會遇到資料庫表被鎖的情況，前些天就又撞見一次。由於業務突發需求，各個部門都在批量操作、導出數據，而資料庫又未做讀寫分離，結果就是：資料庫的某張表被鎖了！

用戶反饋系統部分功能無法使用，緊急排查，定位是資料庫表被鎖，然後進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點贊收藏，以備不時之需。

用戶反饋某功能頁面報502錯誤，於是第一時間看服務是否正常，資料庫是否正常。在控制台看到資料庫CPU飆升，堆積大量未提交事務，部分事務已經阻塞了很長時間，基本定位是資料庫層出現問題了。

查看阻塞事務列表，發現其中有鎖表現象，本想利用控制台直接結束掉阻塞的事務，但控制台賬號許可權有限，於是通過客戶端登錄對應賬號將鎖表事務kill掉，才避免了情況惡化。

下面就聊聊，如果當突然面對類似的情況，我們該如何緊急響應？

想像一個場景，當然也是軟體工程師職業生涯中會遇到的一種場景：原本運行正常的程序，某一天突然資料庫的表被鎖了，業務無法正常運轉，那麼我們該如何快速定位是哪個事務鎖了表，如何結束對應的事物？

首先最簡單粗暴的方式就是：重啟MySQL。對的，網管解決問題的神器——「重啟」。至於後果如何，你能不能跑了，要你自己三思而後行了！

重啟是可以解決表被鎖的問題的，但針對線上業務很顯然不太具有可行性。

下面來看看不用跑路的解決方案：

遇到資料庫阻塞問題，首先要查詢一下表是否在使用。

如果查詢結果為空，那麼說明表沒在使用，說明不是鎖表的問題。

如果查詢結果不為空，比如出現如下結果：

則說明表（test）正在被使用，此時需要進一步排查。

查看資料庫當前的進程，看看是否有慢SQL或被阻塞的線程。

執行命令：

該命令只顯示當前用戶正在運行的線程，當然，如果是root用戶是能看到所有的。

在上述實踐中，阿里雲控制台之所以能夠查看到所有的線程，猜測應該使用的就是root用戶，而筆者去kill的時候，無法kill掉，是因為登錄的用戶非root的資料庫賬號，無法操作另外一個用戶的線程。

如果情況緊急，此步驟可以跳過，主要用來查看核對：

如果情況緊急，此步驟可以跳過，主要用來查看核對：

看事務表INNODB_TRX中是否有正在鎖定的事務線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個sleep的線程事務一直沒有commit或者rollback，而是卡住了，需要手動kill掉。

搜索的結果中，如果在事務表發現了很多任務，最好都kill掉。

執行kill命令：

對應的線程都執行完kill命令之後，後續事務便可正常處理。

針對緊急情況，通常也會直接操作第一、第二、第六步。

這裡再補充一些MySQL鎖相關的知識點：資料庫鎖設計的初衷是處理並發問題，作為多用戶共享的資源，當出現並發訪問的時候，資料庫需要合理地控制資源的訪問規則，而鎖就是用來實現這些訪問規則的重要數據結構。

根據加鎖的範圍，MySQL裡面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（metadata lock，MDL)。

表鎖是在Server層實現的，ALTER TABLE之類的語句會使用表鎖，忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現，而對於InnoDB來說，一般會採用行級鎖。畢竟鎖住整張表影響範圍太大了。

另外一個表級鎖是MDL（metadata lock），用於並發情況下維護數據的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時會被自動加上。

常見的一種鎖表場景就是有事務操作處於：Waiting for table metadata lock狀態。

MySQL在進行alter table等DDL操作時，有時會出現Waiting for table metadata lock的等待場景。

一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態，後續對該表的任何操作（包括讀）都無法進行，因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現了鎖等待隊列，就會造成災難性的後果。

通過show processlist可以看到表上有正在進行的操作（包括讀），此時alter table語句無法獲取到metadata 獨佔鎖，會進行等待。

通過show processlist看不到表上有任何操作，但實際上存在有未提交的事務，可以在information_schema.innodb_trx中查看到。在事務沒有完成之前，表上的鎖不會釋放，alter table同樣獲取不到metadata的獨佔鎖。

處理方法：通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然後kill掉，讓其回滾。

通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進行中的事務。很可能是因為在一個顯式的事務中，對錶進行了一個失敗的操作（比如查詢了一個不存在的欄位），這時事務沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。

處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。

總之，alter table的語句是很危險的（核心是未提交事務或者長事務導致的），在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務、也沒有顯式事務中的報錯語句。

如果有alter table的維護任務，在無人監管的時候運行，最好通過lock_wait_timeout設置好超時時間，避免長時間的metedata鎖等待。

關於MySQL的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。