MySQL InnoDB ext3 塊大小
我正在尋找有關使用 InnoDB 的 MySQL 5.6 的 ext3 文件系統塊大小的建議。
在 VMware ESXi 5 中執行 CentOS 5.4 虛擬機，在 NetApp FibreChannel LUN（具有 4k 塊大小）上的 VMFS 5 數據儲存。使用 O_DIRECT，innodb_flush_log_at_trx_commit = 2，14G 緩衝池，db 執行 OLTP，偶爾會有一些大型查詢處理大量數據。有些表是幾 GB 或更多，有些則非常小。表和 ibdata 文件在一個文件系統上，binlogs 和 ib_logfiles 在另一個文件系統上，因此它們可以有不同的塊大小。
我知道 InnoDB 使用 16k 塊大小，這不是使用者可配置的，所以我想知道是否值得將 ext3 塊大小設置為匹配，而不是預設的 4k。
謝謝！
文件系統塊大小不應該對 InnoDB 產生不良影響。我不是在談論微小的 cpu-bound 性能，因為它的文件系統成本非常小。您應該擔心的是 IO 性能。
當 mysql 需要從磁碟讀取 InnodDB 頁面時，它會訪問文件的 inode 結構。ext3 inode 包含對 15 個塊的引用。前 12 位直接指向數據塊。其餘 3 個指向塊，包含其他塊引用，這些引用也可能是直接的或間接的。
因此，如果 InnoDB 頁面位於文件的第一個 (124)=48KB - 它將在 2 個 IO 操作中獲取：1 個用於 inode，第二個用於數據塊，如果它位於第一個 (124 + 1024)*4 = 4.2MB，3 個操作，(12+1024+1024^2)4=4GB - 4 個操作，(12bs+1024+1024^2+1024^3)*4=4TB - 5 個操作。
1024 是 4k 塊中 4 字節塊引用的數量。
預讀（寫入的預分配）和記憶體將減少此計數，允許一次讀取/寫入多個塊。
4k 的塊大小與 linux 記憶體頁面大小相同，使頁面記憶體更易於編碼。
第一次寫入 Innodb 頁面時，ext3 將預分配 8 個順序塊（32kb）並寫入其中 4 個，其他 4 個將被丟棄（或用於多一個頁面）。此頁面的所有更改都將儲存在相同的塊中。
減少塊大小只對節省磁碟空間有好處，因為 1 個塊是儲存在磁碟上的最小數據單位。
增加它（有一些核心更新檔可以做到這一點）將提高非常大文件的性能，但不會像您想像的那樣提高。將其與 InnoDB 頁面大小相匹配是沒有意義的，因為在絕大多數情況下，一個 InnoDB 頁面的數據塊將按順序放置在磁碟上，並且將在單個操作中讀取/寫入。
