MySQL 中的表空間、.frm 和 .ibd 文件和數據庫頁面之間有什麼關係？
我查看了文件，但沒有關於他們的關係的明確答案，有人可以給出他們在 MySQL 中關係的真實例子嗎？
數據庫頁是數據庫中最小的讀寫單元，通常為 8KB，但是：
- MySQL 頁面和 .frm & .ibd 文件之間有什麼關係？
- .frm 文件是否由許多頁面組成？
- 如果是這樣，那麼 .frm 文件在其中的頁面上是否有任何類型的資訊？
- 喜歡每個頁面的位置和類似的東西嗎？
- 我在哪裡可以閱讀更多關於此的資訊？
- 那麼表空間呢？
- 每個 .frm 文件都是一個表空間嗎？
我花了幾個小時閱讀他們的文件，但這讓我更加困惑
（我說的是 InnoDB 儲存引擎 BTW）
（@jynus 有很好的答案；希望我能補充他的答案，不要重複太多，也不要不同意。）
部分困惑來自InnoDB 的演變。
請記住，90% 以上的 MySQL 使用者可以完全忽略“表空間”並且做得很好。了解它們要麼是學術練習，要麼在某些情況下對磁碟管理很重要。
一開始，在 32 位機器上，只有一個表空間，
ibdata1. 但是，如果這還不夠大（請記住，有些機器的文件限制為 2GB ），還有ibdata2等等。從技術上講，這是一組“表空間”，但並沒有被吹捧為這樣。無論如何，
ibdata1作為 InnoDB 東西的主要位置的概念仍然存在。最初，所有表和索引的所有塊都位於 ibdata1 中。一個問題是，現在仍然是，釋放的空間作為空閒塊留在 ibdata1 中，並且無法返回給作業系統。
為了允許將表放在不同的磁碟上，並允許您
DROP或ALTER表並將空間還給作業系統，innodb_file_per_table. 因此，此時， ibdata1 包含雜項內容，以及（可選）一些表。各種.ibd文件每個都包含一個表（包括索引）或一個PARTITION表。
PARTITIONing允許將表格分成“子表格”，每個子表格幾乎完全像一張表格。這仍然不允許良好的磁碟管理。儲存為 file_per_table 的一千個小表會浪費大量磁碟空間。將不同的數據庫放在不同的文件系統上很麻煩。等等因此，出現了一個更通用的“表空間”。
大約在同一時間，“tmp”和“undo”空間的處理變得很重要。過去，這些都是在 ibdata1 中單獨處理的。但是有互斥體減速等，所以它們傳播開來。
那麼如何處理 5.7 及更高版本中的“表空間”呢？
計劃A：忽略他們。預設值可能已經足夠好了。
計劃 B：每個數據庫一個表空間。不幸的是，沒有“自動”的方式來做到這一點。
計劃 C：遵循 80-20 規則。對於將消耗 80% 磁碟空間的 20% 表，請使用 file_per_table。其餘的，讓他們轉到 ibdata1（或每個數據庫的表空間）。
元資訊的歷史更簡單：
Pre-8.0：
.frm文件包含架構，沒有數據；ibdata1 包含更多資訊。8.0+：新的“數據字典”在 InnoDB 表中。（引導是可怕的。）它包含模式和許多其他東西。萬一 DD 被淹沒並且您需要重建架構，磁碟上有一個文件。
塊：
每個表空間（ibdata*、.ibd）總是被分成塊。最初，只有一個選擇：16KB。您可能聽說過 1MB(?) 或 8MB(?) 的“範圍”——這只是預先分配了一堆塊。這對 HDD 稍微有利，但對 SSD 可能無用。
雖然可能有 4/8/16/32/64KB 的 InnoDB 塊，但 99% 以上的使用者堅持使用預設的 16KB。它們基於某個索引（數據的主鍵或二級索引的輔助鍵）組織在 B+樹中。一個方便的經驗法則：100 個項目儲存在 BTree 塊中。相關：一百萬行的表（或索引）大約有 3 層深。