在具有数百万行的 MySQL 表中进行高效查找答案

【问题标题】：Efficient lookup in MySQL table with millions of rows在具有数百万行的 MySQL 表中进行高效查找
【发布时间】：2012-12-26 16:48:06
【问题描述】：

我有一个包含大约 2000 万行的 CSV 文件，我想在我的 Web 应用程序中使用它。数据是邮政编码到实际街道地址的映射，格式如下：

[zip_or_postal_code] [street_number] [street_name] [city] [state_or_province] [country]

我的目标是将查找（按邮政编码/邮政编码搜索）保持在 200 毫秒以下。

我不确定这是否会有所作为，但我正计划执行以下操作：

我可以做哪些优化来帮助提高查找速度？例如，Google 的反向地理定位 API 在 300 毫秒内返回结果，其中包括 HTTP 开销。他们是怎么做到的？

另外，我对使用其他数据库持开放态度，但由于我已经在使用 MySQL，那会更好。

编辑：查找将始终通过邮政编码完成，例如：给定邮政编码 12345，我需要返回街道#( s)/姓名、城市、州和国家。但是，街道#(s)/name(s) 将存储为单个字符串字段，因此我的应用将负责解析它们。

【问题讨论】：

表的 DDL 是什么？你有索引吗？什么是典型的查询（给出 SQL）？如果您添加这些详细信息，可能会更容易发表评论。
您是否尝试过基本情况（一个索引在zip_code 上的普通表）？我不相信你需要为此做任何特别的事情。
@seandavi：感谢您的评论。我对数据库还不太了解，所以只能解决查询问题。
@BrendanLong：我还没有，不，因为我的数据包含相同邮政编码的多个条目。我必须先清理它，然后才能导入它，但我认为拥有约 10-1500 万行的表会导致查找缓慢，不是吗？
@jam3s17 你应该继续假设这会正常工作。按照数据库标准，20M 行并不大，所以我怀疑您会对带有邮政编码索引的简单表的性能感到惊讶。

【解决方案1】：

2000 万行对于 MySQL 来说并不算多。只需索引邮政编码，它会很快。速度低于 200 毫秒。无需在表之间拆分。当结果集很大时，MySQL 确实会变慢，但您似乎不会遇到这个问题。对于像您这样的基本查询，MySQL 可以处理数亿条记录。

您需要调整 MySQL 设置以使其使用更多内存。默认设置非常低。

MySQL 确实支持空间索引。因此，您可以提取邮政编码的经度/纬度并使用空间索引进行邻近搜索。不过，您似乎不是在寻找那个。

如果你真的想要速度非常非常快，那就按照你的想法去做，但使用 memcache 或 redis。您可以使用邮政编码作为查找键。您仍然需要一个基于持久磁盘的数据存储来从中加载数据。我不认为 memcache/redis 是必需的，但它是一个选项。

【讨论】：

听起来很有希望，谢谢！我会尽快清理我的数据并尝试您的建议。我不知道 MySQL 可以处理这么多记录。我会在运行一些测试后立即更新/接受。
我用过的最大的表有大约 5 亿条记录。简单查询没有性能问题。
太棒了！用 400 万（原始）行进行了测试。通过我的合并脚本运行它（如问题中所述）并将数据集缩小到约 750k 行。探查器告诉我，在 RAM 少于 1 gig 的 VM 中查找所需的时间不到一毫秒（什么？？？）。另外，感谢您指出空间索引支持。看起来很有趣。