- стоит ли делать индекс по первичному ключу таблицы кластерным, если первичный ключ - строковый изначально неупорядоченный uuid? На базе много дедлоков из-за вставок, думаем над переводом проблемных таблиц в кучи.
однозначного ответа тут нет и многое зависит от дизайна в целом но обычно ответ - нет, не стоит есть классический набор требований к кластерному индексу narrow, immutable, monotonic у вас не выполняются полтора (или два, это уж как посмотреть)
Роман, спасибо! Почитаю про эти требования
а целостность данных не нужна? может промежуточные таблицы для первичной вставки использовать, а потом класть в табличку с Int первичным
как целостность данных связана с параметрами индекса?
мы архитектуру БД менять не можем, а сторонний вендор (разработчик БД) помогать с проблемой дедлоков не спешит, хочет чтобы мы решали на уровне DBA. Поэтому думаем про перевод на кучи, про read commited snapshot, отключение эскалации блокировок, партицирование проблемных таблиц и так далее
автор написал сал об идее сделать кучи
а что потом сторонний вендор предлагает делать при обновлении продукта, которое затронет схему? вы сейчас озвучиваете чудовищный сценарий
если вставок много, но они идут не во много потоков, быстро и через хранимки, то можно попробовать черзе app lock сделать эти вставки де-факто последовательными. У нас сработало как промежуточное решение, но время выполнения очевидно вырастает, ибо один вызов хранимки ожидает, пока отработает предыдущий
Тут получается надо вендору предлагать, самим в хранимки лучше не лезть. Попробуем тоже, спасибо
как вариант, на клиенте открывать транзакцию и делать эти локи на том уровне, а потом уже делать вызов хранимки из клиента. Тогда лезть не надо будет.
вы можете это гипотетически сделать через instead of тригеры
Обсуждают сегодня