我有一个数据库表，里面全是来自Google地图地理编码响应的地址。Google缩写了所有的方向（West -> W，East -> E，等等）。
因此，如果我输入一个地址，比如 "100 West Pender Street"，那么谷歌地图返回的格式化地址是 "100 W Pender St"，我将其插入到我的表中。
现在如果有用户来搜索这个地址，以下所有的内容都应该匹配。
Pender streWest Pender street100 Pender100 W Pender100 West Pender(西彭德街)
表中的 "W "被忽略了，因为它低于最小字长。落在东潘纳的地址在搜索结果中的权重相等（"E "也被忽略）。
处理这个问题的最好方法是什么？
我怀疑将最小字长设置为1是一件 "坏事"。
我可以针对google地址中已知的缩写（N、E、S、W、St、Ave、Dr等）进行搜索和替换，并用它们的扩展名来替换--但有一些街道名是无效的（有些城市的街道名是单字母的：J街等......）。
另外像 "123 160 St "这样的地址根本搜索不到，因为街号（123）和街名（160）都低于最小字长。
MySQL FullText是正确的方法吗？ Sphinx有提供更好的东西吗？
还是有其他我没有考虑过的解决方案？请记住，用户的搜索查询不仅会与房产地址匹配，还会与其他文本列匹配，如房产名称和描述。
这其实是一个非常困难的问题--如果你是一个人的话。我在地址验证行业工作，在一家叫做 SmartyStreets我们的产品就在那里执行您所描述的任务。这是一个复杂的操作序列，将地址搜索匹配到有效的，甚至是可交付的端点。准确、正确、完整地执行地址查询的认证称为CASS认证。
谷歌的结果与CASS认证结果的区别在于，谷歌的算法是 "最佳猜测"。这是Google擅长的......不幸的是，这也适用于那些不完全有效的地址。(请看 https:/smartystreets.comdocswhy -wont -my -address -validate.)
用MySQL进行模糊查询会有结果，你的代码可以有算法来帮助，但不能保证准确性和有效性，甚至在这种情况下，没有任何价值。
我想你不会希望你的用户在查询时得到错误的地址回报。这让你的服务显得不合格，用户也不会得到他们期望的价值（对吧？我建议你找一个CASS软件的供应商。例如，你可以在Google上搜索 "地址验证"--我可以推荐的最好的、基于网络的解决方案是SmartyStreets's。美国街道地址API.