Mysql 主键中的日期是否会在范围扫描中获得性能？

我们有大量（且不断增长）的鸟类记录MySQL数据库。目前，我们有三个主要表格，简化如下：

RECORDS (id, birdid, tripid, gender, age) PRIMARY KEY id
BIRDTRIPS (id, locid, date, starttime, endtime, notes) PRIMARY KEY id
LOCATIONS (id, description, centerlat, centerlng) PRIMARY KEY id

所有ID均为整数，日期为日期类型

为了获得性能，我决定通过将date和locid复制到记录中来进行一些非规范化：

RECORDS (id, birdid, tripid, gender, age, locid, date) PRIMARY KEY id

通过这种方式，许多查询将避免昂贵的连接到birdtrip和位置

MySQL每个表只有一个聚集索引，这始终是主键。我被诱惑了
尝试对记录执行主键（日期，id），利用聚集索引对日期列进行更快的范围扫描并对表进行分区。id仅包含在密钥中，因为同一日期可能有许多记录。 从理论上讲，主键通常在id上有点“浪费”，在id上，非聚集唯一索引就足以进行查找

现在我的问题是：

---

你们中有谁有这种方法的实践经验吗？有什么我可能忽略的缺点吗？

我会回答我自己的问题，以防有人偶然发现。我发现了这篇非常好的博客文章，其中对这种方法的性能进行了测试：

blogpost中进行的实验结论如下：

优点：

在我的例子中，使用复合主键是

主键（date，id）

，可以将日期范围查询速度提高大约九倍

随着表的增长，日期范围查询的性能将保持不变，而如果主键仅在“id”上，则性能将逐渐降低

缺点：

使用复合索引时，对“id”列（例如表上的联接）的简单查找速度几乎要慢三倍

较大的聚集索引会显著提高磁盘利用率。这是因为所有其他索引都指向聚集索引，这意味着较大的聚集索引会增加所有其他索引的大小。这可能会导致查询的缓存命中率降低，因为表中可以放入内存的部分会减少

因此，如果针对表的查询的主要部分是业务关键日期范围查询，并且您的系统可以“承受”查询的代价，那么这种方法可能会对您有所帮助

我自己的结论是，我不敢在生产中这样做。相反，我将对日期列的年份进行表分区，以防止对日期范围查询进行全表扫描

希望这能帮助面临类似挑战的人