Можно ли создать индекс «Покрытие, Пространство» в SQL Server 2008? - PullRequest
7 голосов
/ 28 августа 2009

В настоящее время у меня есть сайт с таблицей, в которой есть столбцы с широтой / долготой и индексом по этим двум столбцам плюс еще один, который мне нужно получить.

Я постоянно запрашиваю эту таблицу, чтобы получить строки, попадающие в радиус от определенной точки (на самом деле я получаю квадрат для скорости), но мне нужны только поля, которые уже проиндексированы, поэтому этот индекс на самом деле покрытие, и план выполнения имеет только 2 шага:

Index Seek  (cost: 100%) and SELECT (cost: 0%)

Теперь я пытаюсь воспользоваться пространственными особенностями SQL 2008. Я создал столбец Geography, заполнил его, создал пространственный индекс, все работы.

И все работает нормально, за исключением того, что план выполнения имеет миллион шагов, и 74% времени тратится на поиск кластерного индекса, где он соединяет строки, найденные в пространственном индексе, с реальной таблицей, чтобы получить остальные данные ...
(Поиск пространственного индекса занимает 1% от стоимости плана выполнения)

Итак, по-видимому, он использует пространственный индекс надлежащим образом и находит нужные мне записи намного быстрее, чем раньше, с моим «обычным» индексом по широте / долготе, но соединение с основной таблицей УБИВАЕТ меня, пространственный запрос В 7 раз длиннее моего старого.

Есть ли способ добавить больше столбцов к пространственному индексу, чтобы он покрывал и мог делать вещи за один шаг, точно так же, как это делал раньше?
Есть ли другие вещи, которые я мог бы сделать, чтобы улучшить эту ситуацию?


ОБНОВЛЕНИЕ: я обнаружил, что "обычные" индексы могут "включать" другие столбцы с помощью ключевого слова INCLUDE (о котором я не знал, я обычно просто включал столбцы в сам индекс)
Согласно документации здесь , этот пункт не является опцией для пространственных индексов ... Есть идеи?

Спасибо!
Daniel

1 Ответ

4 голосов
/ 23 февраля 2010

Нет, к сожалению, в настоящее время нет способа создать охватывающий пространственный индекс - запрос всегда выполняет поиск закладок в базовой таблице, чтобы получить географическое значение для строки.

Для STIntersects это, безусловно, всегда необходимо, поскольку нам все еще необходимо выполнить дополнительный фильтр для фактического географического объекта, чтобы убедиться, что он фактически пересекает объект параметра. Однако если вам не требуются точные ответы и вы можете использовать Filter (), то можно будет предоставить столбцы первичного ключа из индекса, вообще не выполняя поиск в базовой таблице. Поддержка этого - кое-что, что мы рассматриваем для следующего выпуска.

С точки зрения ускорения текущего запроса, пытались ли вы использовать Filter () и настраивать индекс с выводом из sp_help_geography_index?

...