Цитата:
Сообщение от
smoyk
Ну возможно, но в этом случай поиск будет идти много медленее, т.к. набор данных не будет упорядочен. Поэтому думаю, что даже в этом случае вызов SETCURRENTKEY будет оправдан.
То что Вы указываете SETCURRENTKEY заставляет сиквель лишь упорядочить то, что получится в результате выполнения запроса. Сама выборка будет выполнятся в соответствии с планом запроса, составленного сиквелем когда-то ранее. План сиквель выбирает сам.
Цитата:
Сообщение от
smoyk
Естественно, но так как мы сортируем именно по полям, по которым проводим поиск, то никакие другие примеры здесь не уместны Вызывая SETCURRENTKEY мы не только сортируем (что значительно ускоряет поиск), но и явно указываем выбираемый ключ. Если SQL 2005 выберет другой ключ исходя из своей логики, думаю это будет не правильно. Думаю, он этого и не сделает имхо. Или я не прав и Вы можете такие примеры привести?
Наблюдаю массу примеров. Ставлю ключ по таблице - сиквель начинает выполнять Clustered Index Seek. Убираю - вот вам Индексный поиск. Ситуация имеет тенденцию самопроизвольно меняться до наоборот . С ключом Index Seek. Без ключа Clustered Index Seek (логично). Замучившись окончательно понять логику стали прицеплять принудительно планы выполнения к каждому из запросов. Утомительная задачка вышла, однако. На казалось бы одну и ту же примитивную конструкцию в C\AL коде сиквель генерит довольно много разных вариаций одного и того же запроса ( иногда отличающихся лишь одним знаком - напр '<' вместо '<='). И для каждого из таких запросов, как я понял, надо приципить свой план. Геморройно... Или надо что-то не так делать? Может мы не так лечим и надо действительно сделать обновление статистики и сиквель должен начать правильно выстраивать планы выполнения? Или можно как-то назначить план на группу запросов?