MySQL：从MyISAM转换为InnoDB可以使查询更快……？

Question

我有一个表，其中包含3,000,000行，其中包含IP范围及其相应的国家，地区（省）和城市。 该表位于MyISAM引擎中。

我编写了一个脚本，通过用户IP获取用户的地理位置，其中一些查询最多需要17秒的时间。 然后，我将表转换为InnoDB并重试了查询过程，其中一些已知的耗时的问题查询在性能上已得到显着改善，而仅需0.02秒。 尽管仍然需要2到3秒钟来完成查询，但是在MyISAM引擎上运行时，查找大约1000个IP地址所花费的全部时间大约是以前的一半。

我在网上进行了一次搜索，比较了MyISAM和InnoDB，但我阅读的所有文章都认为，在SELECT查询中，MyISAM比InnoDB快。 但是，根据我所看到的，这不是我的桌子的情况。 有人有任何理论为什么吗？

PS，我的表没有FK约束，没有PK，通过将IP与每一行的'ip_start'和'ip_end'列进行比较来查找。 如果IP在范围内，则该行将匹配。 以下是我的脚本中的示例查询：

SELECT country, region, city FROM ip_location WHERE ip_start<=1177798832 AND ip_end>=1177798832 LIMIT 1;

Answer 1

检查两个引擎的配置。 与设置MyISAM的方式相比，InnoDB引擎的配置可能对您的搜索更有效。

一个关键的配置值是innodb_buffer_pool_size，这是InnoDB缓存数据（和索引，但是您没有任何索引）的地方。

Answer 2

我找到了一篇有关InnoDB vs MyISAM的好文章 ，其中谈到了性能：

当有问题的查询使用某个范围的主键时，这种集群主键技术是MyISAM和InnoDB之间的基准中有相当大的空白的原因之一。 不过，令人惊讶的是，InnoDB仍在使用二级索引的测试中获胜。 这令人欣慰，因为它表明引擎的性能不仅基于键集群，而且性能的提高很大程度上取决于查询。

InnoDB还对索引使用了其他技巧。 它可以为频繁查询建立“自适应哈希索引”，并且当整个表都快要适合内存时才这样做。[5] 这些哈希索引比标准BTree索引（当表在内存中时）快很多。 同样，这是另一个显着的性能改进，但以内存使用为代价。

您的表听起来很大，所以我怀疑它是否完全保留在内存中，但是听起来InnoDB的索引处理要比MyISAM更好，而且由于您是如此具体，可能正在缓存查询结果。