TSQL: заменяет лучше, чем ltrim/rtrim

Является заменой лучше, чем ltrim/rtrim. У меня нет пробелов между словами, потому что я запускаю его по ключевому столбцу.TSQL: заменяет лучше, чем ltrim/rtrim

update [db14].[dbo].[S_item_60M] 
    set [item_id]=ltrim(rtrim([item_id])) 

Item_id having non-clustered index

Должен ли я отключить индекс для повышения производительности?

Windows 7, 24GB RAM , SQL Server 2014

Этот запрос был запущен в течение 20 часов, а затем я отменил его. Я думаю, что для повышения производительности мне нужно запустить Replace вместо ltrim/rtrim.

SSMS студия разбилась.

Теперь я могу видеть, что это работает в Activity Monitor

Error Log says FlushCache: cleaned up 66725 bufs with 25872 writes in 249039 ms (avoided 11933 new dirty bufs) for db 7:0

Пожалуйста, руководство и предложить мне.

источник

2014-10-09 user3380585

Сколько строк вы пытаетесь обновить? Вероятно, вы должны включить обновления в «куски», например. 10 000 строк за один проход. – gvee

Почему бы просто не попробовать, если есть разница, он должен отображаться, даже если вы запускаете запрос на меньший образец (100, 1000, 10 000? ...) и «сравниваете фактические планы выполнения» – DrCopyPaste

Кроме того, , вы, вероятно, можете ускорить обновление, если вы вытащите все содержимое из производственной таблицы db сначала в табличную переменную, например, вычислите там изменения (т. е.имеют 2 столбца один для исходного 'item_id' для обрезанной этой переменной таблицы), затем запустите обновление в фактической производственной таблице, присоединив вашу переменную таблицы (это может не ускорить весь запрос, но это должно уменьшить блокировку на производственная таблица) – DrCopyPaste

Пропускная способность массовых обновлений не зависит от одного вызова в строке до ltrim или rtrim. Вы произвольно выбираете какой-то очень заметный элемент вашего запроса и считаете его ответственным за плохую производительность. Посмотрите на план запроса, чтобы посмотреть, что делается физически. Также ознакомьтесь с методами массового обновления (например, сбрасыванием и воссозданием индексов).

Обратите внимание, что вопреки распространенному мнению, массовое обновление со всеми строками в одном утверждении обычно является самым быстрым вариантом. Эта стратегия может привести к блокировке и большому использованию журнала. Но обычно имеет лучшую пропускную способность, поскольку оптимизатор может оптимизировать все DML, которые вы выполняете в одном плане. Если расщепление DML на куски было почти всегда хорошей идеей, SQL Server просто сделал бы это автоматически как часть плана.

источник

2014-10-09 10:31:15 usr

Спасибо за комментарий. Расскажи мне больше об этом. Мой стол бездействует. Это тестовая база данных, и на этом компьютере должен быть запущен только один оператор обновления. Не должно быть блокировки вообще. – user3380585

Любые конкретные вопросы? – usr

@ user3380585 'no locking at all' это на самом деле невозможно;) – DrCopyPaste

Не думаю, что REPLACE против LTRIM/TRIM является длинным полюсом в исполнении палатки мудрым. У вас есть параллельная активность против таблицы во время обновления? Я предлагаю вам выполнить эту операцию во время окна обслуживания, чтобы избежать блокировки с другими запросами.

Если количество строк будет обновлено (более 10% или около того), я предлагаю вам отказаться (или отключить) некластеризованный индекс в столбце item_id, выполнить обновление, а затем создать (или включить) индекс после этого. Укажите подсказку фиксации TABLOCKX.

источник

2014-10-09 10:55:14

Спасибо за ответ. Это тестовая база данных и бездействует. Это недавно установленный sql-сервер 2014, и на нем нет операции sql. Мне нужно удалить ненужные атрибуты из этого 60-миллионного стола размером 95 ГБ. – user3380585

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

Если есть несколько строк, которые уже не имеют пробелов, исключите их из UPDATE с помощью предложения WHERE, такого как CHARINDEX ('', item_id) <> 0. Но самый важный совет (уже отправленный выше gvee) - делать UPDATE в партиях (если у вас есть ключ, который вы можете использовать для подкачки). Еще один пример (возможно, если у вас достаточно свободного места) будет использовать операцию, которая может быть минимально зарегистрирована (в модели с большим объемом или простое восстановление): используйте SELECT INTO в другую таблицу, а затем переименуйте эту таблицу.

источник

2014-10-11 18:34:54

Эй, спасибо. Как это сделать партиями? В моей таблице нет ключа. И добавление идентичности к нему будет очень медленным. Есть ли какой-либо трюк для обновления в пакете с использованием TOP (в то время как 1 = 1 обновление вверх 1000 ...)? – user3380585

TSQL: заменяет лучше, чем ltrim/rtrim

ответ

Смежные вопросы