По отношение на SQL Server, това е посочено като повратна точка, за която публикацията в блога на Кимбърли е добре прочетена. http://www.sqlskills.com/BLOGS/KIMBERLY /category/The-Tipping-Point.aspx
Повратната точка е насока от 25%-33% от общия брой страници в таблицата, изразени като редове, напр. 10 000 страници с данни ще дадат повратна точка от 2500-3333 реда. Що се отнася до насоките, това е доста добро и толкова добро, колкото ще получите - не забравяйте, че механизмът на плана за заявка е черна кутия и макар да ви дава план за заявка, той казва само какво е решил, а не защо.
От гледна точка на подсказването на покриващ индекс обаче, това всъщност не е много лесно, дори и при 100% от избраните данни, покриващият индекс все още ще търси сканиране в повечето случаи.
Това има смисъл, ако смятате, че оптимизаторът на разходите не присвоява никакви реални разходи към йерархията на страниците на индекса, а само струва достъпа до крайните страници на индекса. В този момент сканирането или търсенето на 100% от покриващ индекс струва същото.
Открих от собствените си експерименти (http://sqlfascination.com/2009/11/07/can-a-covering-nc-index-be-tipped ) използването на клауза между би го накарало да сканира, но други клаузи where не биха - от това, което можах да кажа, беше чисто до маршрута през системата за заявки.
