2010-11-30 3 views
2

Что может сделать одну таблицу существенно медленнее другой? Вероятно, проще всего просто иллюстрируют:Что сделало бы таблицу «медленной?»

Запрос 1:

select top 1000 * 
from call c 
JOIN call_task ct ON c.call_no=ct.call_no 
LEFT JOIN memo_clt m ON m.doc_ref=ct.record AND m.doc_type='CLT' AND m.line_no=1 
LEFT JOIN memo_clt m2 ON m2.doc_ref=ct.record AND m2.doc_type='CLT' AND m2.line_no=2 

Запрос 2:

select top 1000 * 
from call c 
LEFT JOIN ext_document_detail edd ON edd.doc_type='CLH' 
              AND edd.doc_ext_no=21 
              AND edd.doc_ref=c.record 
LEFT JOIN ext_document_detail edSource ON edSource.doc_type='CLH' 
               AND edSource.doc_ext_no=22 
               AND edSource.doc_ref=c.record 

Структура таблиц похожа, и я доступ к ext_document_detail с очень похожи присоединиться по сравнению с таблицей memo_clt. Однако второй запрос занимает 40 секунд, а второй - 0 секунд.

Оба имеют кластерный индекс для трех ключей, которые я использую для соединения. В таблице memo_clt есть некластеризованный индекс в столбце записи, хотя ... это единственное различие, которое я могу обнаружить, и я не думаю, что это будет иметь большое значение.

Итак, почему разница в скорости здесь?

EDIT: Так спросил Мартин, вот результаты SET STATISTICS IO ON Query 1:

Table 'memo_clt'. Scan count 2000, logical reads 6454, physical reads 0, read-ahead reads 0, lob logical reads 2385, lob physical reads 0, lob read-ahead reads 0. 
Table 'call_task'. Scan count 1, logical reads 39, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 25, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

Запрос 2:

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'ext_document_detail'. Scan count 1001, logical reads 1507004, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 24, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

Сразу две вещи поражает меня. Во-первых, нет такой таблицы, как «Рабочий стол». Второе - это абсолютно огромное количество логических чтений ... что могло бы вызвать это?

+0

Каковы фактические планы выполнения для обоих? Что делает «SET STATISTICS IO ON» для обоих? – 2010-11-30 22:54:47

+0

RE: ваш комментарий ** нет такой таблицы, как «Рабочий стол». ** Я предполагаю, что хеш-соединение находится в фактическом плане выполнения? – 2010-11-30 23:10:22

ответ

2

Это не сами таблицы, которые вызывают разницу в скорости. Это структуры объединений и поддерживающие индексы на запрашиваемых таблицах.

Чтобы дать вам вескую причину разницы в скорости, мне нужно будет увидеть ваш план выполнения. Я подозреваю, что в одном запросе используются индексы лучше, чем другие.

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

Я бы дал this article хороший читать. Это определенно стоит проверить и понять.