最好的 MyISAM 和 InnoDB
由於 RAM 的限制，是否可以使 InnoDB 使用與 MyISAM 相同的索引而不是聚集索引，同時獲得其並發性能的好處？
InnoDB 引擎蓋下的gen_clust_index（聚集索引）包含主鍵條目和 rowid。使用 gen_clust_index 的有趣之處在於，您創建的任何非唯一索引將始終具有表的 gen_clust_index 對應的 rowid。因此，總是存在雙索引查找，一個用於二級索引，一個用於 gen_clust_index。
由於 gen_clust_index，任何改進表或主鍵佈局的嘗試都會被取消，或者至少是邊緣結果。
例子
有些人試圖按 PRIMARY KEY 順序對 MyISAM 進行排序。根據MySQL 數據庫設計和調整，第 236 頁第 7 段，在“以索引順序儲存表”小標題下：
如果您經常從表中檢索大範圍的索引數據或對同一索引鍵的結果進行一致的排序，您可能需要考慮使用 –sort-records 選項執行 myisamchk。這樣做會告訴 MySQL 以與索引相同的物理順序對錶的數據進行排序，並有助於加快此類操作的速度。或者，您可以將 ALTER TABLE 語句與 ORDER BY a specific column 選項結合起來，以獲得相同的結果。
當然，這對MyISAM有效且有效。您可以針對 InnoDB 執行 ALTER TABLE … ORDER BY col1,col2,…,coln，其中列可能是也可能不是 PRIMARY KEY 的列。這不會為 InnoDB 產生更快的結果，因為……沒錯……您必須每次都查閱 gen_clust_index。
有些人可以使用 FIXED 將表格的行格式設置為 FIXED，
ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;並且可以在不進行任何其他更改的情況下將讀取性能提高 20%。這對MyISAM有效且有效。這不會為 InnoDB 產生更快的結果，因為……沒錯……您必須每次都查閱 gen_clust_index。您可以在名為 mydb.mytb 的 InnoDB 表上執行以下操作：
CREATE TABLE mydb.mytc LIKE mydb.mytb; INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln; ALTER TABLE mydb.mytb RENAME mydb.mytd; ALTER TABLE mydb.mytc RENAME mydb.mytb; DROP TABLE mydb.mytd;這將在 gen_clust_index 中按 rowid 順序放置表。這可能最多對 InnoDB 產生邊際結果，因為……這是正確的……您必須每次都查閱 gen_clust_index。
現在，讓我們有點荒謬。有一個 NoSQL 介面用於查詢（僅限 SELECT）MyISAM 和 InnoDB，稱為HandlerSocket（以前稱為 HANLDER）介面。這使您可以訪問數據，從而繞過所有 SQL、ACID和MVCC協議。儘管有可能，恕我直言，編碼和維護太複雜了。AFAIK 沒有任何內容說明 HandlerSocket 介面是否與 gen_clust_index 互動。
總之，有很多方法可以給貓剝皮。在這種情況下，您無法抓住貓（gen_clust_index）。我想這就是為什麼 MyISAM 因其讀取性能、表格排序的靈活性、表格行格式以及支持它的工具而繼續存在的原因。InnoDB 將繼續圍繞其符合 ACID 的特性進行設計，直到某個勇敢的靈魂採用 InnoDB 原始碼並將其轉換為同時具有 MyISAM 和 InnoDB 最好的東西。