Jeśli chodzi o SQL Server, zostało to określone jako punkt krytyczny, o którym warto przeczytać wpis na blogu Kimberley. http://www.sqlskills.com/BLOGS/KIMBERLY /category/The-Tipping-Point.aspx
Punktem krytycznym jest wytyczna 25%-33% całkowitej liczby stron w tabeli, wyrażona w wierszach, np. 10k stron danych dałoby punkt krytyczny 2500-3333 wierszy. Zgodnie z wytycznymi jest to całkiem dobre i tak dobre, jak to tylko możliwe – pamiętaj, że silnik planu zapytań jest czarną skrzynką i chociaż poda plan zapytań, mówi tylko o tym, co zdecydował, a nie dlaczego.
Jeśli chodzi o przechylanie indeksu pokrycia, nie jest to w rzeczywistości bardzo łatwe, nawet przy wybranych 100% danych indeks pokrycia nadal będzie w większości przypadków szukał przeskanowania.
Ma to sens, jeśli weźmiesz pod uwagę, że optymalizator kosztów nie przypisuje żadnych rzeczywistych kosztów do hierarchii stron indeksowych, a jedynie koszt dostępu do stron liści indeksu. W tym momencie skanowanie lub wyszukiwanie 100% indeksu pokrycia kosztuje tyle samo.
Znalazłem z własnego eksperymentu (http://sqlfascination.com/2009/11/07/can-a-covering-nc-index-be-tipped ) użycie klauzuli between spowodowałoby skanowanie, ale inne klauzule where nie – z tego, co mogłem stwierdzić, sprowadzało się to wyłącznie do trasy przez silnik zapytań.
