昨天，我將 MySQL 資料庫轉儲到 SQL 檔案並重新命名為 ibdata1 檔案。然後我重新建立它並匯入 SQL 文件，並將新的 ibdata1 檔案移至我的 MySQL 資料目錄，刪除舊檔案。
我以前做過，沒有問題，但這次有些不對勁。當我檢查（個人的，不是 MySQL 配置）資料庫時，它們都在那裡，但它們是空的……有點像。資料目錄仍然包含 .ibd 文件，其中包含正確的內容，我可以查看該表清單在資料庫中，但不在表本身。 （我啟用了每個表文件，並使用 InnoDB 作為所有內容的預設值。）
例如與網址資料庫及其網址表，我可以成功開啟 mysql.exe 或 phpMyAdmin 和use urls;.我什至可以show tables;看到預期的表，但是當我嘗試describe urls;or時select * from urls;，它抱怨該表不存在（即使它只是列出來）。 （MySQL管理員列出了資料庫，但甚至沒有列出表，這表明資料庫完全是空的。）
現在的問題是我已經刪除了 SQL 檔案（即使在搜尋硬碟後也無法恢復它）。所以我想找出一種方法來修復這些資料庫/表。我無法使用表修復功能，因為它抱怨該表不存在，並且我無法轉儲它們，因為它再次抱怨該表不存在。
正如我所說，資料本身仍然存在於 .ibd 檔案中，並且表名稱也存在。我只需要一種方法讓 MySQL 識別資料庫中存在這些表（我可以使用十六進位編輯器在 ibdata1 檔案中找到相關表的列名）。
知道如何修復這種類型的損壞嗎？我不介意捲起袖子，埋頭苦幹，採取一系列措施來解決這個問題。
多謝。
答案1
嗯，我嘗試了很多東西，研究了很多命令、開關和結構（毫不奇怪，MySQL 文件是最有幫助的，如果廣泛的話——needle/haystack）。最終我的一些技巧奏效了（事實證明其他人也想到了同樣的技巧，儘管我沒有在一個地方看到恢復表結構和恢復數據兩個主要部分，所以我將它們一起發布這裡）。
我必須做的是重新建立 IBDATA1 檔案。不幸的是，當執行守護程序檢測資料庫（目錄）時，它不會取得內部的 Innodb 表（IBD/FRM 檔案）。所以我所做的是：
- 清空資料目錄（或移動原始目錄並建立一個空目錄）
- 運行守護程序，讓它建立一個新的空 IBDATA1 文件
- 使用 SQL 腳本匯入系統表
…\MySQL\share - 建立同名的虛擬資料庫和表
- 複製原始FRM文件
- 使用其中一個
DESCRIBE或更好的方法SHOW TABLE CREATE來提取表結構 - 接下來，我
DISCARD TABLESPACE在桌子上使用 - 複製原始 IBD 文件
- 然後我用了
IMPORT TABLESPACE - 最後，我重新運行守護程式
innodb-force-recovery=6 - 我跑去
mysqldump提取結構和數據
當然，事情並不總是一帆風順。有些表很好，但有些需要在 後刪除表和資料庫SHOW TABLE CREATE，並在嘗試匯入資料之前使用它重新建立表。其他人甚至沒有工作那麼遠，我必須使用十六進制編輯器從 FRM 文件中手動獲取列的註釋和名稱（儘管弄清楚數據類型和屬性、鍵等是什麼是一件很糟糕的事情）射擊）。此外，還有大量（太多）守護程式和客戶端重新啟動。
（我仍在尋找一種可以直接解析 FRM/IBD 文件（或至少顯示 FRM 文件中的表結構）的工具，但似乎沒有人費心對它們進行“逆向工程”，即使它是開源的並且文件格式是公開的。
關鍵是始終使用絕對最小值（例如僅 MYSQL 目錄，即係統表）。不幸的是，雖然這意味著事情會被簡化並且更容易使用，但它也意味著一次恢復一張表——這對我來說不是什麼大問題，但對某些人來說可能是大問題。
無論如何，在過去幾天我在網路上看到的許多 MySQL 恢復頁面中，有一小部分非常有用，一旦我搜尋我的歷史記錄以挖掘它們，我就會添加它們。
希望這可以幫助處於類似情況的其他人。
答案2
能夠列出所有表和資料庫通常意味著 *.frm 檔案在那裡。他們並不意味著他們有任何數據。您是否嘗試啟動 mysqld 進程強制innodb恢復？如果沒有的話試試，當然了，啟動時mysql日誌說了什麼？
完成後：永遠不要再嘗試使用這樣的備份。