Posso creare un indice "Covering, Spatial" in SQL Server 2008?

Question

Attualmente ho un sito con una tabella con colonne lat/long float e un indice su queste due colonne più un altro che devo recuperare.

Sto interrogando costantemente questa tabella per ottenere le righe che rientrano in un raggio da un certo punto (in realtà sto ottenendo un quadrato per la velocità), ma ho solo bisogno dei campi che sono già indicizzati, quindi questo indice è infatti di copertura, e il piano di esecuzione ha solo 2 passi:

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

Ora, sto cercando di sfruttare le caratteristiche spaziali di SQL 2008. ho creato la colonna Geografia, riempita, creato l'indice spaziale, i lavori.

E tutto funziona correttamente, tranne che il piano di esecuzione ha un milione di passaggi e il 74% del tempo viene speso per una ricerca indice cluster, dove unisce le righe trovate nell'indice spaziale alla tabella effettiva, per ottenere il resto dei dati ...
(l'indice spaziale Seek prende 1% del costo piano di esecuzione)

Quindi, a quanto pare, si sta usando l'indice spaziale in modo appropriato e trovare i dischi che ho bisogno di molto più veloce di prima con il mio indice "normale" su Lat/Long, ma l'unione con la tabella principale è KOLING me, la query Spatial richiede 7 volte il tempo di mia precedente.

C'è un modo per aggiungere più colonne all'indice spaziale in modo che copra e possa fare le cose in un unico passaggio, proprio come faceva prima?
Ci sono altre cose che potrei fare per migliorare questa situazione?

---

UPDATE: ho scoperto che "regolari" gli indici possono "includere" altre colonne utilizzando la parola chiave INCLUDE (che io non conoscevo, ho usato per includere solo le colonne nell'indice stesso)
Secondo alla documentazione here, quella clausola non è un'opzione per gli indici spaziali ... Qualche idea?

Grazie!
Daniel

Answer 1

No, purtroppo non esiste attualmente alcun modo per creare un indice spaziale di copertura: la query eseguirà sempre la ricerca dei segnalibri nella tabella di base per ottenere il valore di geografia della riga.

Per STIntersects, questo è chiaramente sempre necessario poiché è ancora necessario eseguire il filtro secondario sull'oggetto geografico effettivo per verificare che intersechi effettivamente l'oggetto parametro. Tuttavia, se non si richiedono risposte esatte e si può usare Filter(), allora sarebbe possibile fornire le colonne della chiave primaria dall'indice senza effettuare la ricerca sulla tabella di base. Sostenere questo è qualcosa che stiamo prendendo in considerazione per la prossima versione.

In termini di accelerazione della query corrente, hai provato a utilizzare Filter() e a ottimizzare l'indice con l'output sp_help_geography_index?