MySQL中主键的选择与磁盘性能

偶然看到了“Fotolog: Scaling the World's Largest Photo Blogging Community”，才发现很多数据库的优化其实道理都很简单，至高境界是当你面对问题时，是否真正做出了自己的思考，而不仅仅只是经验主义的惯性使然：

介绍：图片有很多评论。浏览时会执行：SELECT ... WHERE photo_identifier = ... ORDER BY posted ...

在“Old Schema”的解决方案中，一切都显得中规中矩：使用了最常见的自增字段identifier作为主键，同时使用photo_identifier, posted作为索引。

数据按照主键进行排序，当执行查询时，根据索引进行数据对位。不过这里的问题在于，同一个图片的评论数据，在磁盘上会分散到多个数据页之上。

在“New Schema”的解决方案中，虽然也使用了自增字段，但是采用的是联合主键photo_identifier, posted, identifier，并把identifier作为索引。同时需要注意的是，表类型使用的是Innodb，并缩减了自增字段的长度，这样，主键的长度会短一些，有助于提升Innodb的性能。

数据按照联合主键进行排序，由于photo_identifier字段是联合主键中的第一个字段，所以对于一张图片而言，它所有的评论都保存在磁盘中相邻的位置上。在这种情况下，当对数据进行定位时，Innodb会进行优化：“Pending read”，所谓Pending read，指的是当发生一次read的时候，并不一定是直接从文件系统里“物理read”，而只是从缓冲池中“逻辑read”，Innodb内部的优化机制可以合并多次“逻辑read”为一次“物理read”，从而降低IO消耗，提高磁盘性能。

还有一个问题需要考虑，当使用photo_identifier, posted, identifier联合主键时，如果对一个photo_identifier较小的图片发表评论的时候，数据会记录在比较靠前的数据页上，和直接使用identifier自增主键相比，这样会引起一个不小的IO负担，因为自增主键在添加新数据时，新数据始终位于数据文件的结尾。所以，实际应用中，文中所示的方法是否可用，还要从客观情况分析而定，比如说评论主要集中在新图片上，则IO问题不大，因为新图片的记录位于数据文件靠后的位置上，但是如果评论分布的图片比较随机的话，那么此方法是否适用则需要斟酌，不过也可以变通着来，比如说在主从服务器的结构里，我们可以在主服务器上使用identifier自增主键，在从服务器上使用photo_identifier, posted, identifier联合主键，这样既保证了写操作的效率，也保证了读操作的效率。