Ну короче мы ничего и не поняли.... :)

LI 3.9.25

Ярослава, ну извиняйте... :( Вот так всегда... хочешь чего нибудь сказать... ;)
Ну да ладно, все это ерунда, зато в понедельник на работу пойду почти как на праздник ;) Просто надоело уже в этом учебном центре... Единственное - там кормят хорошо! :D Шведский стол, большой выбор и никаких ограничений :D:D:D

Исходное сообщение Elusive_Lover: Ярослава, ну извиняйте... :( Вот так всегда... хочешь чего нибудь сказать... ;)
Ну да ладно, все это ерунда, зато в понедельник на работу пойду почти как на праздник ;) Просто надоело уже в этом учебном центре... Единственное - там кормят хорошо! :D Шведский стол, большой выбор и никаких ограничений :D:D:D

Вот это я понимаю... :)

LI 3.9.25

Elusive_Lover, про оптимизатор потом расскажешь поподробнее, хорошо? :)
а вот с индексами - в зависимости от их наличия время выполнения запроса может меняться на порядок - сама видела несколько раз :)

Ярослава, да уж ;) Тема там такая... Вкуууснааяяяя ;) Правда потом после такого сытного обеда мозги плохо соображают :D Везде свои минусы...

Scheddi, да не вопрос ;)
Весь оптимизатор - это и есть песня о индексах, планах и стоимости ;) Вообще всю кухню M$ не раскрывает, и предлагает на собственном опыте в ходе лабораторных убедится как надо и как не надо, учитывая что все равно последнее слово останется за оптимизатором. Самый выразительный пример элементарный select по индексу. Если оптимизатор видит что в результате работы индекса фильтруется слишком много записей то он просто игнорирует индекс и читает всю таблицу. Вот например если из 10000 записей в результате работы индекса выбирается 500 - это уже много! И считается что прочесть 10000 быстрее!! О как! А вот если 150- тогда можно и по индексу пойти ;) Так что иногда индексы - бесполезны

Elusive_Lover, не знаю точно, поскольку сама не пользовалась, но кажется есть способы самому определить план выполнения запроса. Хотя, очень может быть, с чем-то другим путаю.

Scheddi, да можно. Если указать в запросе чтобы оптимизатор не оптимизировал. Правда MS это не рекомендует База все время меняется, и вчерашний выгодный план сегодня может стать совсем не выгодным ;) На самом деле оптимизатор - штука вумная ;) и то поведение которое я описал - оно как нистранно тоже вполне логично и объяснимо ;) Связанно с физической организацией размещения таблиц в базе. а так же с типом индекса. Например некластерный индекс - это просто ссылка-указатель на ту страницу данных где находятся данные. Минимальный отрезок чтения в SQL измеряется страницами. Каждая страница- 8060 байт. Т.е. в зависимости от типа данных это от нескольких сот до нескольких тысяч записей. Когда SQL составляет план выполнения запроса по индексу, он смотрит в первую очередь на последовательность, и частоту обращений. Если в результате такого индекса выяснится что нужно несколько раз подряд лезть на одну и ту же страницу, он отбрасывает такой индекс и вместо того чтобы 10 раз читать одну страницу читает по 1 разу все 10 ;) Примерно так ;) Так что все вполне логично. А вообще все эти индексы и планы нужны только в больших таблицах с миллионами записей, иначе толку от них мало.