我有一个应用程序，其中基本上我有庞大的信息表（100万条记录），包含纬度/长值的每一行。
我经常查询该表来获取所有适应周围的某一点的半径范围内的记录。 例如，“5英里39.89288内的所有记录，-104.919434”
对于这一点，我有过纬度/长列的索引，而我得到的“边界广场”点，然后丢弃所有的落在我的ASP.Net应用圈外的点，因为这是更快不是做在SQL Server中圈计算。
注意：这是对美国的所有数据，所以我考虑地球是平的为我的计算，这是足够精确的满足我的需求。
现在，随着纬度/龙指数最主要的问题是，作为点的“方形”，因为我想找到“X和Y之间纬度”和“龙X和Y之间”，它不能真正使用索引超高效的，因为它可以，如果我经点的“一条线”搜索。
我一直在阅读了关于SQL 2008的空间特征，但我还没有找到足够的具体信息，知道这是否是对我来说非常有用。
所以，问题是：是否SQL 2008具有某种不同类型的索引的，这将使此特定类型的查询比我快得多与SQL 2005？
是! 看看这篇文章关于空间索引。 你会看到，这些类型的索引工作比“索引矩形”的方式更好。 此外，您不仅能够有效地查询“是附近的另一个点地”，而是做其他类型的地理操作。 下面是对类型的所有可用方法的完整列表。
发现这一点：
对于SQL 2008：
http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/sql-server-2008-proximity-search-with-th
显然，这是可能的
注：该文章的SQL 2005的版本不执行太清楚了。 我试过那种东西，它工作得更好，只是从SQL Server中的广场，然后宰杀自己的代码的圈子。
感兴趣的更多链接：
http://msdn.microsoft.com/en-us/library/bb964712.aspx
（最后的解释!!）
而一个简单的查询......显然，这是如何做到我想要的搜索（5英里圈内分）：
DECLARE @Location GEOGRAPHY
SET @Location = GEOGRAPHY::STPointFromText('POINT(73.9517061 40.7934358)',4326).STBuffer(5 * 1600);
SELECT [fields] FROM [table] WHERE LocGeog.STIntersects(@Location) = 1
（LocGeog是地理列）
奇怪的是，这个管理办法比我普通的旧查询慢（慢7倍），所以我显然还是做得非常错误的。
是的，这可以用SQL 2008空间数据做得非常好。 有在正确的网格级别设置空间索引了一定的专业知识/试错（？），但它应该在这之后是巨大的（通过朋友转发给我，我还没有在生产中使用它自己）。
你的目的（经/纬度），您将WAN上的地理图形类型，而不是地理指标 。 我相信，空间索引成立了“嵌套的边界三角”类型的索引是在预处理，我们被迫在SQL中没有它的“边框”式的改进。
OK，我建议在开始这篇文章在格兰特Fritchey的博客“可怕的DBA之家”（告诉他我给你，如果你要问的问题:-)）。 这是一些性能分析和空间索引，他刚开始学习的调谐一个很好的解释，也包括链接到许多其他材料。
你知道，我在星巴克大约5年前做的纬度/经度查询...
基本上，我们希望店配送中心关联。我在他们的业务部门工作，他们实在一点也分不清哪个店是由一个特定仓库提供。
所以，我最终想出这个“魔圈”算法。
基本上，他们有一堆看起来像这样的查询：选择表1 *，表2凡UdfDistance（table1.Lat，table1.Long，table2.Lat，table2.Long）> = 250
最后我想出的东西真的similiar，但它跑快了很多
SELECT * FROM表1，表2凡UdfDistance（table1.Lat，table1.Long，table2.Lat，table2.Long）> = 250和（table2.Lat - 1）之间table1.Lat和（table2.Lat + 1）和表1之间。长（table2.Long - 1）和（table2.Long + 1）
Basically-不要尝试，如果有超过1度（lat和长）两者之间的差异比较2个地点。
在其它words-它使用师范大学关系索引过滤掉了很多的值，然后将UDF距离计算有很多较少的信息来处理。
希望帮助，我会尽力帮助澄清，如果我需要
