Таблица SQL Server с 1,2 миллионами строк и 400+ столбцами очень медленная даже при простом подсчете (*)

Question

Я использую SQL Server 2008 R2, и у меня есть таблица, скопированная из таблицы DB2. Я знаю, что количество строк не является нормальным, но это историческое событие, и сейчас я ничего не могу с этим поделать.

Но простой подсчет строк занимает более 2 минут. Таблица состоит из 3 столбцов с индексированными идентификаторами клиентов, остальные - поля с десятичными числами.

Поиск, подобный этому:

select 
    AD_ARBNUM, AD_SHBETSA, AD_AMBIDSHBETSA,AD_ASKATSHBETSA
from 
    lmoko 
where 
    AD_SHBETSA + AD_AMBIDSHBETSA + AD_ASKATSHBETSA < 0

, где AD_ARBNUM индексируется, а остальное десятичное число занимает 3+ минуты.

При запуске в DB2 тот же запрос выполняется менее чем за 20 секунд. (Я не знаю об индексации в части DB2)

Есть предложения по ускорению работы здесь?

Answer 1

Это предложение WHERE добавляет три разных столбца вместе, а затем сравнивает их со значением.Для этого SQL SErver должен сканировать всю таблицу.Любая функция против столбца, подобного этой, приведет к сканированию таблицы.По мере роста таблицы запросы будут становиться все медленнее и медленнее.

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

Answer 2

(В моем ответе излагаются первые несколько комментариев, просто для подробностей и некоторого контекста.)

Индексы SQL используются для «поиска» определенных значений. С индексом AD_ARBUM SQL найдет все строки с заданным значением (скажем, 12) почти мгновенно (если, конечно, половина строк таблицы не установлена ​​в 12, и в этом случае вам придется читать половину стол). Ваш фильтр запросов основан на формуле, основанной на нескольких столбцах, ни один из которых не проиндексирован, поэтому необходимо будет прочитать все эти столбцы - по всем 1,2 миллионам строк, чтобы оценить, какие из них включить, а какие - нет. Если вы построили индекс по всем трем столбцам формулы (AD_SHBETSA, AD_AMBIDSHBETSA, AD_ASKATSHBETSA), ему все равно придется делать одну и ту же математическую формулу для каждого. Если вы построили индекс по самой формуле

CREATE nonclustered INDEX IX_lmoko__ThreeColumnFormula
 on lmokok (AD_SHBETSA + AD_AMBIDSHBETSA + AD_ASKATSHBETSA

тогда SQL может искать и фильтровать в зависимости от значения, которое вас интересует, и должен быть намного быстрее (конечно, при условии, что вы не вернете все строки в конце концов.) Недостаток такого индекса это то, что вы должны поддерживать индекс; он займет место, может замедлить вставки и обновления, и если он используется только для запроса, который вы запускаете раз в месяц (а не раз в минуту), это может привести к слишком высокой стоимости производительности и ресурсов.

Кроме того, как указывалось, могут быть и другие факторы: от плохого оборудования до нехватки ресурсов и общего пространства (насколько широкая строка? Сколько столбцов на самом деле задействовано? Эти числовые значения или SQL нужно преобразовать? из строк? Много потенциальных ошибок, о которых мы не можем знать, не глядя на систему)

Answer 3

Если вы просто беспокоитесь о количестве, вы можете запустить:

SELECT SUM (row_count) 
FROM sys.dm_db_partition_stats 
WHERE object_id = OBJECT_ID('lmoko ') AND (index_id=0 or index_id=1);

также есть некоторые вещи, которые вы можете использовать в своей таблице, кроме индексов, например, создание разделов для хранения старых данных.