SQL-запрос с несколькими индексами - SQL Server 2000 - PullRequest
0 голосов
/ 29 января 2010

Я использую подобный запрос, как этот

select.....from.. with... (INDEX=IX_TABLE_1, INDEX=IX_TABLE_2)...

Я получаю следующую ошибку

Только один список указателей на таблицу разрешено

Кажется, это хорошо работает с SQL Server 2005. Это проблема с SQL-сервером?

Ответы [ 2 ]

3 голосов
/ 29 января 2010

I думаю это может быть из-за синтаксиса, который вы используете.

Вместо (INDEX = IX_TABLE_1, INDEX = IX_TABLE_2) попробуйте:

(INDEX=IX_TABLE_1, IX_TABLE_2)

Я думаю, это факт, что у вас есть 2 "INDEX =" части.

Кроме того, я бы рекомендовал использовать подсказки индексов в качестве крайней меры, поскольку оптимизатор запросов обычно выбирает лучший план / индексы для использования. Вот почему, как правило, вы должны доверять оптимизатору. Если вы используете индексные подсказки, рекомендуется просматривать их довольно часто, так как со временем они могут ухудшиться (например, по мере роста объемов данных то, что первоначально было лучше с подсказкой, может начать работать хуже).

0 голосов
/ 29 января 2010

На самом деле, вы не должны давать указатели в первую очередь.

Объяснение

  1. Одна из целей языка SQL состоит в том, чтобы отделить «что» от «как». Другими словами; ваши запросы должны указывать правила наборов результатов, которые вам требуются, а не пути доступа к данным (именно это и делают подсказки индекса).
  2. Связывая ваши запросы с определенными индексами, вы теряете возможность повышать производительность, добавляя улучшенные индексы. То есть Вы также должны изменить свои запросы.
  3. Многие опции подсказок зависят от платформы; Вы уменьшаете мобильность, когда используете их.
  4. Оптимизатор запросов был написан с учетом всех индексов, различных сценариев соединения и, что наиболее важно; статистическая информация о данных в ваших таблицах. Даже если вы можете охватить все эти основы самостоятельно и определить идеальные индексы для использования сегодня; через 6 месяцев статистическая частота определенных значений, записей, ссылок в вашей базе данных может измениться - и ваш выбор индекса может перестать быть хорошим!

Примечание стороны

Если оптимизатор делает глупый выбор, какие индексы использовать; это обычно требует дальнейшего расследования.

  • как первый шаг; статистика вашей таблицы достаточно актуальна?
  • Во-вторых, убедитесь, что оптимизатор не отклоняет определенный индекс, поскольку на самом деле указанный индекс снижает производительность . Например, у вас может возникнуть желание выполнить одно из следующих действий:

    SELECT  Col1, Col2, Col3, ...
    FROM    Customers WITH (INDEX=IndexByName)
    WHERE   FistName LIKE 'A%'
    
    SELECT  Col1, Col2, Col3, ...
    FROM    Customers WITH (INDEX=IndexByName)
    ORDER BY FirstName
    

Индексные подсказки кажутся совершенно логичными; однако:

  • Если индекс кластеризован, или индекс покрытия: он будет использован в любом случае - без подсказки.
  • Если индекс не кластеризован и не покрывает: для каждой найденной записи потребуется поиск по закладкам. Это влечет за собой огромное количество накладных расходов; особенно на диске искать активность. Следовательно, индексы, в конце концов, плохой выбор.

Наконец

Я не уверен, так ли это; но ваш вопрос не указывает, что это сложный многостоловый запрос. Так может быть на самом деле так тривиально, как следует?

SELECT  Col1, Col2, ...
FROM    ATable WITH (INDEX=Index1, INDEX=Index2)

Безотносительно ситуации, безусловно, не имеет смысла подсказка нескольких индексов для одной таблицы (если только она не используется несколько раз с самостоятельными объединениями). Вы сказали:

Кажется, это хорошо работает с SQL Server 2005.

И я должен спросить: ты уверен?
Я попробовал это; и насколько это не вызвало сообщение об ошибке - это серьезно смутило оптимизатор. Это заставило оптимизатор дважды пересечь одну и ту же таблицу ( без необходимости ) и соединить наборы результатов друг с другом, что привело к огромным накладным расходам !!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...