Временная таблица или постоянные столы?

Question

Для моей компании я перерабатываю некоторые хранимые процедуры. В исходных процедурах используется множество постоянных таблиц, которые заполняются во время выполнения процедуры, а в конце значения удаляются. Количество строк может увеличиваться от 100 до 50 000 строк для расчета агрегации.

Мой вопрос: будут ли серьезные проблемы с производительностью, если я заменю эти таблицы временными таблицами? Можно ли использовать временные таблицы?

Answer 1

Это зависит от того, как часто вы их используете, сколько времени занимает обработка, и если вы одновременно получаете доступ к данным из таблиц во время записи.

Если вы используете временную таблицу, она не будет сидеть в ожидании индексации и кэширования, пока она не используется. Так что это должно сэкономить очень немного ресурсов там. Тем не менее, вы будете подвергаться накладным расходам с временными таблицами (т.е. создавать и уничтожать).

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

Однако базы данных предназначены для хранения и извлечения информации. Я бы избегал использования постоянных таблиц для обычной временной работы и придерживался временных таблиц.

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

Надеюсь, это поможет,

Джеффри Кевин Прай

Answer 2

Табличные переменные, как правило, путь. SQL2K и ниже могут иметь значительные узкие места в производительности, если манипулируют многими временными таблицами - проблема заключается в блокировке DDL для системных таблиц.

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

Большой вопрос, может ли более чем один человек одновременно выполнять одну из этих хранимых процедур?Я регулярно вижу таблицы такого рода, перенесенные из старых однопользовательских баз данных (или от программистов, которые не могли выполнять подзапросы или что-либо еще, кроме SELECT * FROM).Что произойдет, если более чем один пользователь попытается запустить одну и ту же процедуру, что произойдет, если в середине произойдет сбой - будет ли таблица очищена?С помощью временных таблиц или табличных переменных у вас есть возможность правильно настроить таблицу только для текущего соединения.

Answer 6

Я согласен с Джеффри.Это всегда зависит.Поскольку вы используете Sql Server 2008, вы можете взглянуть на табличные переменные .
Они должны быть легче, чем таблицы TEMP.

Я определяю пользовательскую функцию, которая возвращает таблицупеременная, как это:

    CREATE FUNCTION .ufd_GetUsers ( @UserCode INT )
    RETURNS @UsersTemp TABLE
        (
        UserCode INT NOT NULL,
        RoleCode INT NOT NULL
        )
    AS
    BEGIN
        INSERT @RolesTemp
            SELECT     
                dbo.UsersRoles.Code, Roles.Code
            FROM    
                dbo.UsersRoles 
                INNER JOIN
                                    dbo.UsersRolesRelations ON dbo.UsersRoles.Code = dbo.UsersRolesRelations.UserCode 
                INNER JOIN
                                    dbo.UsersRoles Roles ON dbo.UsersRolesRelations.RoleCode = Roles.Code
            WHERE dbo.UsersRoles.Code = @UserCode

        INSERT @UsersTemp VALUES(@UserCode, @UserCode)



RETURN
END

Answer 7

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