В отместку он взламывает школьную систему и переделывает расписание так, чтоб оказаться в одном классе с Кейт.
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
Засовывать varchar(max) в included-колонки индекса - так себе практика.
Согласен, вроде и не утверждал обратного, хотя иногда и приходится.
Computed колонки лучше делать persisted
Можете пояснить - зачем persisted? Зачем хранить и в кластерном индексе, и в самом индексе, если они мне особо и не нужны, а только для оптимизации запроса?
computed persisted-колонку LEFT(x, 200) и индекс по ней - если реально данные не длиннее 200 символов.
Зависит от того, какая средняя длина. Я предпочитаю объявлять больше, чтобы не было спилов в tempdb, если в выборке будут слишком длинные varchar'ы.
DROP INDEX ix_ON ON smth (field2_calculated);
GO
ALTER TABLE smth
DROP COLUMN field2_calculated;
GO
ALTER TABLE smth
ADD field2_calculated AS LEFT(field2, 200) PERSISTED;
GO
CREATE INDEX ix_ON ON smth (field2_calculated);
GO
Msg 1919, Level 16, State 1, Line 18 Column 'field2_calculated' in table 'smth' is of a type that is invalid for use as a key column in an index.
Явно приводить тип всё равно нужно.
Не забывайте ещё, что varchar(max) хранятся в куче
Не то, чтобы я активно топил за то, чтобы не делать ребилды индексов, но всё зависит, как минимум, от объёма активной порции данных. Если он не влезает в память, то похоже, что пора идти в магазин.
Более того, MS, оказывается, переписали свой whitepapper по перестройке индексов и там прямо пишут, что зачастую положительный эффект, наблюдаемый после ребилда - это следствие обновления статистики, а не ребилда как такого.
Тот же Озар, емнип, идёт ещё дальше и пишет, что зачастую и обслуживание статистики это "оверинжениринг", а эффект проявляется из-за того, что процедурный кэш инвалидируется.
Так может лучше вообще не трогать индексы на таких системах? Не насиловать регулярно диски, а лучше почаще выполнять checkdb?
Ну, т.е. пост же как раз об этом - перестройка индексов стандартными средствами может дать какой-то минимальный прирост производительности (если он вообще будет), но потребует кучу ресурсов, сгенерирует тонну логов, инвалидирует кучу планов и может вызвать блокировки (на не-Enterpise редакции).
В вашем примере как раз только процент заполненности страницы и может сыграть какую-то роль. Памяти же фрагментированные индексы, заполненные на 100 процентов будут занимать столько же, сколько и совсем не фрагментированные.
Не совсем понял, что имеется в виду. Оверинжениринг - это обслуживать индексы в принципе? Или оверинжениринг - это не использовать стандартные планы обслуживания?
Полез в словари искать незнакомое слово и не нашёл.
Зато нашёл глагол «Транскрибировать», значением которого оказалось «Производить транскрипцию».
Значит правильно называется, спасибо.
Мы хотим попробовать выкинуть in-memory таблицу в отдельную бд на том же сервере, где вообще нет не-inmemory таблиц. В основной базе таблицу грохнуть и создать под её именем синоним, который будет смотреть на таблицу в новой бд. Если получится, такую базу и в ag можно будет включить, чтобы вместе ездили в случае файловера.
А вы проверяли размер файлов относящихся к этой базе с помощью, прошу прощения, файлового менеджера?
На диске занимает столько же, сколько я получаю запросом к sys.database_flies. Воспроизвести эту ситуацию и посмотреть размер на диске с помощью вашего любимого файлового менеджера вы можете минуты за 3 с использованием скриптов в посте.
А почему не использовать sp_executesql? Проблему с SQL Injection он по крайней мере решит.
Ага, именно поэтому на следующий день устраивает скандал из-за того, что видит, что он компьютер к сети подключил
Не смог пройти мимо. В отместку он всё-таки взламывает школьную систему и вызывает "протечку бассейна", а в класс с ней записывается для собственного удовольствия
Я правильно понимаю, что раз статья опубликована человеком с подписью "редактор Хабра" - то теперь это тематика Хабра, а не какого-нибудь VC или Пикабу?
Логика не двоичная используется с null.
В else "идёт" то, что не true. unknown - не true, поэтому попадает в else.
Если не знаешь, что операции сравнения с null возвращают unknown, который не true, и не false, то да, сплошное удивление.
Спасибо за статью! Не пользуюсь SQLite, но про внутренности БД всегда интересно читать)
Согласен, вроде и не утверждал обратного, хотя иногда и приходится.
Можете пояснить - зачем persisted? Зачем хранить и в кластерном индексе, и в самом индексе, если они мне особо и не нужны, а только для оптимизации запроса?
Зависит от того, какая средняя длина. Я предпочитаю объявлять больше, чтобы не было спилов в tempdb, если в выборке будут слишком длинные varchar'ы.
Явно приводить тип всё равно нужно.
зависит от реальной длины строки
Я имена вычисляемых столбцов вообще нигде по тексту не использую - только их определения.
Не то, чтобы я активно топил за то, чтобы не делать ребилды индексов, но всё зависит, как минимум, от объёма активной порции данных. Если он не влезает в память, то похоже, что пора идти в магазин.
Более того, MS, оказывается, переписали свой whitepapper по перестройке индексов и там прямо пишут, что зачастую положительный эффект, наблюдаемый после ребилда - это следствие обновления статистики, а не ребилда как такого.
Тот же Озар, емнип, идёт ещё дальше и пишет, что зачастую и обслуживание статистики это "оверинжениринг", а эффект проявляется из-за того, что процедурный кэш инвалидируется.
Так может лучше вообще не трогать индексы на таких системах? Не насиловать регулярно диски, а лучше почаще выполнять checkdb?
Ну, т.е. пост же как раз об этом - перестройка индексов стандартными средствами может дать какой-то минимальный прирост производительности (если он вообще будет), но потребует кучу ресурсов, сгенерирует тонну логов, инвалидирует кучу планов и может вызвать блокировки (на не-Enterpise редакции).
В вашем примере как раз только процент заполненности страницы и может сыграть какую-то роль. Памяти же фрагментированные индексы, заполненные на 100 процентов будут занимать столько же, сколько и совсем не фрагментированные.
Не совсем понял, что имеется в виду. Оверинжениринг - это обслуживать индексы в принципе? Или оверинжениринг - это не использовать стандартные планы обслуживания?
Ну, Transcribe - Транскрибировать - производить транскрипцию
Зато нашёл глагол «Транскрибировать», значением которого оказалось «Производить транскрипцию».
Значит правильно называется, спасибо.
На видео натыкался, но текст всегда круче).
Для тех, кто снимает диф-бэкапы, такой ваш бэкап может стать огромным (и очень неприятным) сюрпризом. Добавьте ключ COPY_ONLY к бэкапу.
Мы хотим попробовать выкинуть in-memory таблицу в отдельную бд на том же сервере, где вообще нет не-inmemory таблиц. В основной базе таблицу грохнуть и создать под её именем синоним, который будет смотреть на таблицу в новой бд. Если получится, такую базу и в ag можно будет включить, чтобы вместе ездили в случае файловера.
Спасибо!
На диске занимает столько же, сколько я получаю запросом к sys.database_flies. Воспроизвести эту ситуацию и посмотреть размер на диске с помощью вашего любимого файлового менеджера вы можете минуты за 3 с использованием скриптов в посте.