SQL Server Index

имам една таблица
T(
id int има клъстерен индех CI
oid char(4) има индекс OI
tid char(4) има иднекс TI
....
)

защо
select * from T where oid = 'XXX'
не използва OI а сканира по CI
ако насила го накарам да използва този индекс, прави seek по OI обаче после
върти някъв буукмарк лууп по клъстерния индекс за да си намери записите

обаче

select * from T where oid = 'XXX' and tid='YYY'
прави seek по OI и TI и след това прави join резултата и съответно работи доволно бързо

някои има ли идея защо става така, излиза че двата допълнителни индекса са излишни освен ако не правя филтър и по двете полета
и друго някои знае ли в цифри как се отразява добавянето на нов индекс на операцията инсърт

мерси предварително

tuk na pomosht ti idva USE INDEX (key_list) Dosta e polezen :D

точно тава ме притеснява
select * from t with (index = OI) where oid = 'xxx'
работи по-бавно от
select * from t where oid = 'xxx' като във втория случай използва клъстерния индекс
май проблема ми е че заявката връща прекалено много записи и индекса не е ефективен
мерси все пак :)

Една от причините да не ползва нон-цлустерния индекс може да бъде това че данните в таблицата са подредени (по дефиниция) по клъстерния индекс. Това означава че редовете с ОИД='ХХХ' са на различни дата-страници (потенциално всеки на отделна страница) и за всеки от тях сервера трябва да направи по едно допълнително И/О. Оптимизатора събразява това и си казва "е--л съм му майката на нон-цлустерния индекс"

Аз бих пробвал композитен индекс (оид, тид, ид) -- индекса ще съдържа всички необходими колони ( covered query), ведещата колона ти е в вхере клаузата и достъпа би трябвало да намери по индекса първия квалифициран запис и след това да чете последователно листата на индекса докато стигне до следващия ОИД. Малко е разхищение на дисково пространство, но бързината ще се подобри.

Друга причина може да е че таблицата е много малка -- под 10 страници и не си струва да се използва индекс.

Как се отразяват индексите на инсертите -- с една дума зле. Зависи колко инсерти имаш и какъв ти е хардуера. За много активни системи (10000 + инсерта в секунда) препоръчват индексите да не са повече от три на таблица.

Инсертите в таблица с кл. индекс също водят до фрагментиране на таблицата, което е кофти и за селектите. МС СЯЛ сервера има средство за мерене на фрагментацията и ако е голяма, таблицата не е зле да се подреди чрез пресъздаване на клъстерния индекс.

Ако считаш че многото индекси ти забавят инсертите, можеш да създадеш индексите с филлфактор около 80-90%. Дефолта (без филлфактор) оставя на всяка страница место за два допълнителни реда.

Мерси за отговора, особено за статистиката за insert :)

За съжаление когато правя филтър само по едно от полетата
резултат е 10 000 записа и след като направи сиик в индекса по полето за да си намери пълните записи върти нещто по клъстерния индекс.
пробвах да направя сложен индекс - полето + праймари ключа обаче пак продължава да си търси данните по праймари ключа след като филтрира по полето
дали не бъркам нещо?
аз мисля че ако имаме индекс Поле,ПрмКлюч би трябвало след като се сиикне в тоя индекс и намери записите за конкретна стойност на Поле останалото извличане да е светкавично, а на мен ми отнема 95% от заявката
в плана на заявката го нарича 'Bookmark lookup' и казва че използва RID(не го знам кво е) или клъстерния иднекс за да си намери данните
пък и в реалнота таблица клъстерния иднекс ми е от две полета дали и това няма значение ?)

Ако не си направил съхранена процедура да ти връща резултатите - май е време:)))
Идеален случай - търсене само по PrimaryKey - не винаги е възможно.
Добавяне на 1 допълнителен индекс на полето , по което предполагаш, че ще се търси най-често. Аз обикновено спирам до тук...
Но може да се добави още 1 индекс и за друго поле - над 2 индекса вече производителността пада, дисковото пространство се увеличава и т.н.
Ако имаш книга и тя е с 3 съдържания - търсенето ще ти отнеме повече време отколкото на книга с 1 съдържание - много е опростено - все пак зависи от конкретния случай (брой записи, брой полета, тип на данни,....) - ще намериш оптималното решение - сигурен съм:))).

RID е row id -- ново понятие в вер. 7 ако не се лъжа. Нещо като вътрешен примари кий за таблицата.
Аз обаче съм дотук - не съм цар на МС СЯЛ сервер.

МОже би искаш да постнеш ддл-ла на таблицата и плана на заявката та белким се намери някой цар да ги разтълкува.

Също и set statistics io on za da se widi kolko struwa taq zaqwka

ddd