gpt4 book ai didi

sql-server-2008 - 如何加快此 Sql Server 空间查询?

转载 作者:行者123 更新时间:2023-12-04 07:14:17 26 4
gpt4 key购买 nike

关闭。这个问题需要debugging details .它目前不接受答案。












想改进这个问题?将问题更新为 on-topic对于堆栈溢出。

6年前关闭。




Improve this question




我有(我认为)是一个简单的 Sql Server 空间查询:
抓取存在于某个 4 边多边形内的所有美国州(即网页的 google/bing map 的视口(viewport)/边界框)

SELECT CAST(2 AS TINYINT) AS LocationType, a.Name AS FullName, 
StateId, a.Name, Boundary.STAsText() AS Boundary,
CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a
WHERE @BoundingBox.STIntersects(a.Boundary) = 1
运行需要 6 秒 :(
这是执行计划....
已删除
过滤器操作的统计数据...
已删除
现在,我只是不知道如何调试这个 .. 找出我需要微调的内容等。我有任何空间索引吗?我相信是这样 ...
/****** Object:  Index [SPATIAL_States_Boundary]    
Script Date: 07/28/2010 18:03:17 ******/
CREATE SPATIAL INDEX [SPATIAL_States_Boundary] ON [dbo].[States]
(
[Boundary]
)USING GEOGRAPHY_GRID
WITH (
GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH),
CELLS_PER_OBJECT = 1024, PAD_INDEX = OFF, SORT_IN_TEMPDB = OFF,
DROP_EXISTING = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
我需要提供更多关于 GEOGRAPHY 的信息吗?返回的数据是什么?例如。点数等?或者我需要运行 profiler并从那里提供一些统计数据?
还是我的 Cells_per_object/Grids 设置不正确(我真的不知道应该将这些值设置为什么,TBH)。
有人可以帮忙吗?请?
更新/编辑:
在下面@Bobs 的第一次回复确认空间索引没有被使用后,因为主键(聚集索引)将比具有 50 奇数行的表上的非聚集索引更快......然后我试图强制空间索引(对于shits-n-giggles):-
SELECT CAST(2 AS TINYINT) AS LocationType, a.Name AS FullName, 
StateId, a.Name, Boundary.STAsText() AS Boundary,
CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a WITH (INDEX(SPATIAL_States_Boundary))
WHERE @BoundingBox.STIntersects(a.Boundary) = 1
...猜猜是什么..查询立即运行。
怎么回事?其他人知道为什么吗?我是否需要为此发布一个查询计划,以帮助解释为什么/什么?

最佳答案

您似乎有一个运行查询的最佳计划。这将很难改进。以下是一些观察。

该查询正在对 PK_States 索引执行聚集索引扫描。它没有使用空间索引。这是因为查询优化器认为使用聚集索引而不是任何其他索引会更好。为什么?可能是因为 States 表中的行数很少(华盛顿特区、波多黎各等地可能还有 50 行加上其他行)。

SQL Server 在 8KB 页上存储和检索数据。筛选操作的行大小(请参阅 Estimate Row Size)为 8052 字节,这意味着每页有一行,整个表大约有 50 页。查询计划估计它将处理其中大约 18 行(请参阅估计的行数)。这不是要处理的大量行。我的解释没有针对表格中的额外页面,但关键是这个数字大约是 50 页,而不是 50,000 页。

所以,回到为什么它使用 PK_States 索引而不是 SPATIAL_States_Boundry 索引。根据定义,聚集索引包含表的实际数据。非聚集索引指向数据所在的页面,因此需要检索的页面更多。因此,非聚集索引只有在数据量较大时才有用。

您可能可以采取一些措施来减少页面进程的数量(例如,使用覆盖索引),但您当前的查询已经很好地优化了,您不会看到太多的性能提升。

关于sql-server-2008 - 如何加快此 Sql Server 空间查询?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3350965/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com