在MySQL表中高效查找数百万行

Question

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

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

我的目标是在200毫秒内保持我的查找(通过邮政编码搜索).

我不确定这是否会有所作为,但我打算做以下事情:

• 移动state/province,country和city列自己的表和引用这些在我的主表,以避免不必要的膨胀.
• 一些邮政编码包含多个街道和地址,因此我将合并数据并拥有1个邮政编码和邮政编码,并将多个地址存储在varchar中.这应该从表中减少几百万行.

我可以做些什么优化来帮助查找速度？例如,Google的反向地理定位API会在300毫秒内返回一个包含HTTP开销的结果.他们是如何做到的呢？

此外,我愿意使用其他数据库,但由于我已经在使用MySQL,这将是更好的选择.

编辑:查询将始终通过邮政编码完成,例如:给定邮编12345我需要返回街道#(s)/名称,城市,州和国家.街道#(s)/名称将存储为单个字符串字段,但是,我的应用程序将负责解析它们.

Answer 1

对于MySQL来说,2000万行并不是很多.只需索引邮政编码,它就会很快.方式快200ms以下.无需在表之间拆分.当结果集很大时,MySQL确实会变慢,但看起来你不会遇到这个问题.对于像你这样的基本查询,MySQL可以完成数亿条记录.

您需要调整MySQL设置,以便它使用更多内存.默认设置非常低.

MySQL确实支持空间索引.因此,您可以提取邮政编码的经度/纬度,并使用空间索引进行邻近搜索.看起来好像你正在寻找那个.

如果你想要的东西真的非常快,那就去你想要的路线但是要使用memcache或redis.您可以使用zip /邮政编码作为查找键.您仍然需要一个基于持久磁盘的数据存储来加载数据.我不认为memcache/redis是必要的,但它是一个选项.