我还没有找到任何关于mysql的大o的真实数据，从外键和主键选择查询。下面是两个查询示例：
SELECT some_column FROM some_table WHERE primary_key = some_value SELECT some_column FROM some_table WHERE foreign_key = some_value
这两个问题有什么大不了的？谢谢你的帮助！
wfypjpf41#
假设table是 ENGINE=InnoDB ...这个 PRIMARY KEY 与数据“聚集”在一起 WHERE primary_key = some_value 将btree向下钻取到叶节点，它会在那里找到整个记录。二级索引（我假设 foreign_key 也是一个btree，但叶节点包含一个pf的副本 PRIMARY KEY 对于它找到的行。然后执行第二次查找以获取数据（包括 some_column ).基于这种逻辑，次键查找所需的时间大约是pk查找所需时间的两倍。然而，因为在任何一个国家都有很多其他的事情在发生 SELECT 所以你很少测量2倍。还有其他问题。。。如果 some_column 是pk中的一列，然后是第二列 SELECT 就像第一个一样。如果你有 INDEX(foreign_key, some_column) ，则这将更快，因为任务将在向下钻取此键的btree后完成。也就是说，不需要第二个带有pk的探针。如果测试在 WHERE 不涉及索引，则执行“表扫描”。对于一千行的表，查询将花费一千倍的时间(实际上差别并不大，这也是由于开销的关系。）无论如何，在几毫秒内可以扫描1000行，所以在一个“微小”表上丢失索引通常不是什么大问题。这只是索引和优化过程中几十件，也许几百件微妙的事情中的一些小道消息。更多，但不是所有的小道消息都在这里找到。
ENGINE=InnoDB
PRIMARY KEY
WHERE primary_key = some_value
foreign_key
some_column
SELECT
INDEX(foreign_key, some_column)
WHERE
1条答案
按热度按时间wfypjpf41#
假设table是
ENGINE=InnoDB...这个
PRIMARY KEY与数据“聚集”在一起WHERE primary_key = some_value将btree向下钻取到叶节点，它会在那里找到整个记录。二级索引（我假设
foreign_key也是一个btree，但叶节点包含一个pf的副本PRIMARY KEY对于它找到的行。然后执行第二次查找以获取数据（包括some_column).基于这种逻辑，次键查找所需的时间大约是pk查找所需时间的两倍。然而，因为在任何一个国家都有很多其他的事情在发生
SELECT所以你很少测量2倍。还有其他问题。。。
如果
some_column是pk中的一列，然后是第二列SELECT就像第一个一样。如果你有
INDEX(foreign_key, some_column)，则这将更快，因为任务将在向下钻取此键的btree后完成。也就是说，不需要第二个带有pk的探针。如果测试在
WHERE不涉及索引，则执行“表扫描”。对于一千行的表，查询将花费一千倍的时间(实际上差别并不大，这也是由于开销的关系。）无论如何，在几毫秒内可以扫描1000行，所以在一个“微小”表上丢失索引通常不是什么大问题。这只是索引和优化过程中几十件，也许几百件微妙的事情中的一些小道消息。
更多，但不是所有的小道消息都在这里找到。