Показать сообщение отдельно
Старый 18.10.2007, 12:35   #48  
Голышев Михаил is offline
Голышев Михаил
Участник
 
106 / 10 (1) +
Регистрация: 03.07.2006
Цитата:
Сообщение от smoyk Посмотреть сообщение
А мне кажется логичным, что сервер выбирает тот ключ, по которому идет сортировка.
Слава богу SQL 2005 обладает более динамичной логикой, чем выбор ключа по полям сортировки. (привет MySql)

Можно привести массу примеров, где это утверждение не верно.

Более того, порой просто поражаешься сообразительности SQL в аспекте построения плана запросов.
(кстати по мимо поисков по ключу есть и другие компоненты планов - Table Spool'ы, Bookmark Lookup'ы и прочие)
Цитата:
Сообщение от smoyk Посмотреть сообщение
В тоже время без сортировки (без вызова SETCURRENTKEY) выбор ключа не так очевиден, имхо.
Главное, как отметил chebv, следить за статистикой и фрагментацией индексов. Тогда выбор ключа будет постоянен и очевиден.

Цитата:
Сообщение от smoyk Посмотреть сообщение
Кстати, эффект от вызова SETCURRENTKEY увеличился на порядок после создания ключа на сервере
Вполне резонно. Создание любого ключа потенциально увеличивает скорость запросов.
Создайте ключи из всех возможных комбинаций полей во всех возможных порядках и все FIND по таблице будут моментальными. Зато изменения в этой таблице станут ойойой какими медленными.

ps Главное не превращать это в алхимию. Лучше вместо замеров секундомером, использовать хотя бы монитор клиента, а еще лучше профайлер. Тогда будет ясно почему именно произошло ускорение и поможет ли данный метод в других лучаях.