SQL-SERVER Query занимает слишком много времени

Question

У меня есть этот простой запрос, но он занимает всего 1 минуту только для записей 0.5M, даже если все столбцы, упомянутые в select, находятся в некластеризованном индексе.

Обе таблицы содержат около 1М записей и около 200 столбцов в каждой.

Имеет ли большое количество записей в таблице или большое количество индексов, вызывающих медлительность.

SELECT catalog_items.id,
       catalog_items.store_code,
       catalog_items.web_code AS web_code,
       catalog_items.name AS name,
       catalog_items.name AS item_description,
       catalog_items.image_thumnail AS image_thumnail,
       catalog_items.purchase_description AS purchase_description,
       catalog_items.sale_description AS sale_description,
       catalog_items.taxable,
       catalog_items.is_unique_item,
       ISNULL(catalog_items.inventory_posting_flag, 'Y') AS inventory_posting_flag,
       catalog_item_extensions.total_cost,
       catalog_item_extensions.price
FROM catalog_items
     LEFT OUTER JOIN catalog_item_extensions ON catalog_items.id = catalog_item_extensions.catalog_item_id
WHERE catalog_items.trans_flag = 'A';

Обновление: план выполнения показывает, что индекс отсутствует, такой же индекс уже существует. Почему?

Answer 1

Я не уверен, что план в настоящее время неверен, на основании того, что вы упомянули выбор 500 тыс. Строк из таблицы с 1 млн. Строк.Даже с индексом, предложенным другими, селективность этого индекса довольно слабая с точки зрения переломного момента (https://www.sqlskills.com/blogs/kimberly/the-tipping-point-query-answers/) - даже с 200 столбцами я бы не ожидал, что в результате получится 500 тыс. Из 1 млн. Строк на таблицув поиске индекса с поиском полное сканирование будет более быстрым в представлении CBO.

Отсутствующий вопрос об индексе - если вы посмотрите внимательно, он не просто предлагает индекс для trans_flag, он предлагает индексировать поле и затем INCUDE число больше.Мы не можем видеть, сколько он предлагает включить, но я ожидаю, что это будет все из них в запросе, и он в основном предлагает вам создать индекс покрытия.Даже в сценарии сканирования индекса NC это будет выполняться быстрее, чем базовая таблица.

У нас также пока нет информации о физических макетах, о том, как создается страница, об уровне фрагментации и т. Д., И даже о том, какого родадисков данные на и общий размер.Например, это поле image_thumbnail указывает на большой размер строки в целом, что означает, что мы имеем дело с хранением страниц вне страницы в LOB / SLOB.

Короче говоря, даже в плане запроса нет простого ответа.здесь, на мой взгляд.

Answer 2

Для этого запроса

select . . .                                    
from catalog_items ci left outer join
     catalog_item_extensions cie
     on ci.id = cie.catalog_item_id
where ci.trans_flag = 'A'

Я бы порекомендовал индекс для catalog_items(trans_flag, id) и catalog_item_extensions(catalog_item_id).