娛樂後 MySQL 表失去/損壞
昨天我將我的 MySQL 數據庫轉儲到一個 SQL 文件並重命名了 ibdata1 文件。然後我重新創建它並導入 SQL 文件並將新的 ibdata1 文件移動到我的 MySQL 數據目錄，刪除舊的。
我以前做過沒有問題，但是這次有些不對勁。當我檢查（個人，而不是 MySQL 配置）數據庫時，它們都在那裡，但它們是空的……有點。數據目錄中仍然有包含正確內容的 .ibd 文件，我可以查看數據庫中的表列表，但不能查看表本身。（我啟用了每表文件，並且預設使用 InnoDB。）
例如使用urls數據庫及其urls表，我可以成功打開 mysql.exe 或 phpMyAdmin 和
use urls;. 我什show tables;至可以看到預期的表，但是當我嘗試describe urls;or時select * from urls;，它抱怨該表不存在（即使它只是列出了它）。（MySQL管理員列出了數據庫，但沒有列出表，這表明數據庫是完全空的。）現在的問題是我已經刪除了 SQL 文件（即使在搜尋我的硬碟後也無法恢復它）。所以我試圖找出修復這些數據庫/表的方法。我不能使用表修復功能，因為它抱怨表不存在，我不能轉儲它們，因為它再次抱怨表不存在。
就像我說過的，數據本身仍然存在於 .ibd 文件中，並且存在表名。我只需要一種讓 MySQL 辨識數據庫中存在表的方法（我可以使用十六進制編輯器在 ibdata1 文件中找到相關表的列名）。
知道如何修復這種類型的損壞嗎？我不介意捲起袖子，深入研究並採取一系列步驟來修復它。
非常感謝。
好吧，我嘗試了一堆東西並研究了一堆命令、開關和結構（毫不奇怪，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 目錄，即係統表）。不幸的是，雖然這意味著事情會被簡化並且更容易使用，但這也意味著一次恢復一張桌子——這對我來說沒什麼大不了的，但對某些人來說可能是這樣。
無論如何，在過去幾天我在網際網路上看到的許多 MySQL 恢復頁面中，有一小部分是非常有用的，等我翻遍我的歷史來探勘它們時，我會添加它們。
希望這可以幫助其他處於類似情況的人。