Answers:
InnoDB 的gen_clust_index（聚集索引）包含主键的条目以及rowid。使用gen_clust_index的有趣之处在于，您创建的任何非唯一索引都将始终具有表的gen_clust_index的相应rowid。因此，总是存在双索引查找，一个用于二级索引，一个用于gen_clust_index。
改进表或主键布局的任何尝试都将由于gen_clust_index而无效，或者至少充其量只是边际结果。
例
有人尝试按主键顺序对MyISAM进行排序。根据MySQL数据库设计和调整，第236页第7段，在小标题“以索引顺序存储表”下：
如果您经常从表中检索大范围的索引数据或对同一索引键一致地对结果进行排序，则可能要考虑使用--sort-records选项运行myisamchk。这样做可以使MySQL按照与索引相同的物理顺序对表的数据进行排序，并可以帮助加快这些操作的速度。或者，您可以将ALTER TABLE语句与特定列选项的ORDER BY结合使用以达到相同的结果。
当然，这对于MyISAM有效且有效。您可以对InnoDB执行ALTER TABLE ... ORDER BY col1，col2，...，coln，其中列可能是或可能不是PRIMARY KEY的列。这不会为InnoDB产生更快的结果，因为...没错...您每次必须查阅gen_clust_index。
某些人可以使表的行格式为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优点的代码为止。
的聚集索引可能是在对传统的旋转驱动器InnoDB的并发性能的原因。
通过聚集索引访问行的速度很快，因为行数据位于索引搜索所在的同一页上。如果表很大，则与使用不同于索引记录的页面存储行数据的存储组织相比，聚集索引体系结构通常可以节省磁盘I / O操作。（例如，MyISAM将一个文件用于数据行，将另一个文件用于索引记录。）
磁盘I / O昂贵。因此减少它是提高并发性的巨大好处。
如果磁盘I / O开始变得便宜且不再是瓶颈（例如，随着SSD技术变得更加稳定），Oracle可能会决定更改InnoDB索引的工作方式。它更有可能保持不变，因为相同的技术将使“ RAM的限制”成为一个问题。
简短答案：不可以。
InnoDB通过主键集群，并且在没有主键的情况下，它选择第一个唯一索引。在没有唯一索引的情况下，它将创建一个隐藏的6字节密钥用于群集。
当您拥有隐藏的6字节键时，所有二级索引都引用此键，而不是指向行位置的精确指针（如MyISAM中一样），因此最终您将遇到遍历辅助键，然后遍历主键以查找记录的情况。
为了从您的问题中推断出一点，我假设您担心内存是否适合一棵树，因为为了有效地进行搜索，所有根节点都应该位于内存中，因为您总是必须走这条路才能找到叶子页？
的确是这样，但令人欣慰的是，商业数据库试图使它们的树尽可能胖而不是深。尝试对数据运行xtrabackup --stats进行查看。例如：
<INDEX STATISTICS>
table: test/table1, index: PRIMARY, space id: 12, root page 3
estimated statistics in dictionary:
key vals: 25265338, leaf pages 497839, size pages 498304
real statistics:
level 2 pages: pages=1, data=5395 bytes, data/pages=32%
level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%有497839个叶页（约8GB），但仅以上416页（6.5MB）。我已经在生产数据上运行了该命令几次，当我拥有数以亿计的记录并且只有1-3页+叶页时，它总是让我感到惊讶。