Влияние вычисленных столбцов на производительность в базе данных SQL Server 2005?
Ситуация: у нас большая база данных с множеством денормализованных таблиц. Нам часто приходится пересчитывать данные, чтобы сводные таблицы были синхронизированы. Мы то и дело говорили об использовании вычисляемых столбцов для сохранения актуальности данных. Мы также говорили о триггерах, но это отдельная тема.
В наших сводных таблицах мы денормализовали таблицу таким образом, чтобы в таблице сохранялся стандартный идентификатор, а также стандартное описание. Это по сути предполагает, что таблица будет пересчитываться достаточно часто, так что, если они изменят стандартное описание, оно также изменит его в сводной таблице. Плохое предположение.
Вопрос: Что, если бы мы сделали стандартное описание в сводной таблице производным / вычисляемым столбцом, который выбирает стандартное описание из стандартной таблицы? Можно ли сильно снизить производительность, если отбросить вычисляемый столбец в таблице со 100 000–500 000 строками?
Ответы 3
Вычисляемые столбцы хороши, когда они не требуют интенсивных вычислений и не выполняются для большого количества строк. Ваш вопрос: «Будет ли удар, если отбросить вычисляемый столбец». Если этот столбец не является индексом, который используется запросом (ДЕЙСТВИТЕЛЬНАЯ плохая идея для индексации comp col - я не знаю, можете ли вы в зависимости от вашей БД), то его удаление не может повредить вашей производительности (меньше данных для запроса и сжатия ).
Если стандартная таблица имеет описание, вы должны присоединяться к ней по идентификатору и не использовать никаких вычислений.
Вы упомянули, что может быть реальной проблемой, и это схема вашей базы данных. У меня были проблемы, подобные этой, когда система была построена для решения одной задачи, и что-то вроде отчетности нужно было закрепить. Идея Санни об использовании представлений - это чуть ли не единственный простой способ без рефакторинга вашей схемы, чтобы сбалансировать все потребности.
Если вы хотите опубликовать очищенный DDL и данные, а также пример того, что вы пытаетесь получить от базы данных, мы можем дать вам менее субъективный ответ.
Вычисляемый столбец в таблице может быть получен только из значений в этой строке. Вы не можете выполнять поиск в вычисляемом столбце. Для этого вам потребуется вид.
В таблице такая небольшая денормализация имени в таблице, вероятно, окажет незначительное влияние на производительность. Вы можете использовать DBCC PINTABLE, чтобы указать серверу, что таблица должна храниться в кеше.
Если вам нужно, чтобы обновления производились в режиме реального времени, тогда единственный вариант - триггеры. Размещение кластерного индекса в столбце идентификатора, соответствующем обновляемому имени, должно уменьшить общий объем операций ввода-вывода (записи для данного идентификатора будут в одном блоке или наборе блоков), поэтому попробуйте это, если триггеры вызывают проблемы с производительностью.
Просто чтобы прояснить проблему для sql2005 и выше:
This functionality was introduced for performance in SQL Server version 6.5. DBCC PINTABLE has highly unwanted side-effects. These include the potential to damage the buffer pool. DBCC PINTABLE is not required and has been removed to prevent additional problems. The syntax for this command still works but does not affect the server.