|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Идёт к тому, что добавят ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 17:26 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Модератор: Давайте обсуждать болиды Ф1 за пределами этого форума ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 18:00 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
env alexeyvg Разумеется, без внешних ключей запись будет быстрее with nocheck .. nocheck ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 21:42 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Я скажу, что удаление любых ключей или индексов всегда ускорит операции insert/update для таблицы, где убрали ключи, т.к. меньше проверок- меньше инструкций. При этом гарантии ссылочной целостности снизились, теперь старые запросы могут дать другие результаты. Сколько времени позволено БД оставаться в возможно негодном состоянии? Если ноль, то ключи это выполняли. Если можно отложить, то можно проверять и править позже. Я так делал для импорта миллиона строк в справочник, который обновлялся только в нерабочее время. Это не затрагивая OnDelete. Ещё можно ускорить запись если заменить все поля одним blob, но нужно ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 22:22 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
НеофитSQL Я скажу, что удаление любых ключей или индексов всегда ускорит операции insert/update для таблицы, где убрали ключи, т.к. меньше проверок- меньше инструкций. И даже в кучу таблиц, не заботясь о последовательности. Понятно, что во время процедуры вставки база будет в неконсистентном состоянии, и нет гарантии, что она не останется в нём после загрузки. В общем, правильный и исчерпывающий ответ сразу был дан первым же ответом - силён SQL.RU, "все про базы данных и программирование"! env Зависит от целей и задач. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 21:19 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
НеофитSQL Ещё можно ускорить запись если заменить все поля одним blob А можно пример? Желательно на параллельной вставке нескольких миллионов строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 09:29 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
env НеофитSQL Ещё можно ускорить запись если заменить все поля одним blob А можно пример? Желательно на параллельной вставке нескольких миллионов строк. для начала хотя бы на одном десятке с примерами инсерта а также апдейта и делита по условиям и джойнам ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 13:14 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Насколько я знаю, то ли с 16, то ли с 17 MS внесло существенные изменения в работу с внешними ключами для увеличения производительности, особенно при наличии множественных ключей в одной таблице. Можно содрать тестовую базу и поэкспериментировать на нескольких миллионах внешних ключей для вставки - удаления. Скорее, большую проблему может принести наличие дополнительных индексов в дочерней таблице, чем проверка внешнего ключа. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 10:33 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
привет всем, давно не виделись! Владислав Колосов Насколько я знаю, то ли с 16, то ли с 17 MS внесло существенные изменения в работу с внешними ключами для увеличения производительности, особенно при наличии множественных ключей в одной таблице. это очень похоже на пиар и только, вот в этой статье Query optimizer changes in SQL Server 2016 explained товарищ тоже нашел блог, где демонстрируется один новый оператор Foreign Key References Check, даже картинка приводится. вот только не воспроизводится. ни у него, ни у меня. мой сервер: Код: coco 1. 2.
картинка делита на базе в совместимости 150 (от тучи проверок ФК экран разрывается): ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 13:04 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
картинка отвалилась, извиняюсь ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 13:05 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
план тоже прикрепляю, rar, сам план 159Кб и пишут, размером не вышел. хорошее же удаление одной строки, что план в форум не дают запостить ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 13:09 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Yasha123 привет всем, давно не виделись! Владислав Колосов Насколько я знаю, то ли с 16, то ли с 17 MS внесло существенные изменения в работу с внешними ключами для увеличения производительности, особенно при наличии множественных ключей в одной таблице. это очень похоже на пиар и только, вот в этой статье Query optimizer changes in SQL Server 2016 explained товарищ тоже нашел блог, где демонстрируется один новый оператор Foreign Key References Check , даже картинка приводится. вот только не воспроизводится. ни у него, ни у меня. [/src] картинка делита на базе в совместимости 150 (от тучи проверок ФК экран разрывается): можно ссылку на болд что это за зверь - почитать ps я правильно понял что удаляется таблица на к-ю есть ссылки с других таблиц план конечно серьзеный а в реальности удаление проходит быстро ? pps нашел там же In SQL Server 2016, the Foreign Key References Check is introduced to handle all referential integrity checks in a single step. Microsoft’s documentation indicates that this change will greatly simplify execution plans and reduce compilation time for the execution plan. т.е это на усмотрение оптимизатора ? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 15:56 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Yasha123, это очень похоже на пиар А вот это похоже на правду. т.к. я возлагал определенные надежды на эти самые улучшения, но результат не увидел. Списал на свою малограмотность. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 16:33 |
|
Внешнии ключи и скорость
|
|||
---|---|---|---|
#18+
Гулин Федор можно ссылку на болд что это за зверь - почитать ps я правильно понял что удаляется таблица на к-ю есть ссылки с других таблиц план конечно серьзеный а в реальности удаление проходит быстро ? ссылка там выше. а так да, все правильно, когда на таблицу смотрит туча ФК из еще сотни таблиц, этот оператор должен был заменить в плане 100 NL с теми таблицами одним оператором. и типа план быстрее компилируется и все счастливы. откуда бы счастью быть, непонятно, ибо все эти ФК все равно проверять придется. и если там нет индексов по нужному полю, то и будет скан 100 таблиц, помноженный на число удаляемых строк. но по факту и план тоже остался с сотней проверок ФК, так что экран раздирается. ну а скорость удаления зависит от размера индексов/самих таблиц с ФК. --- у нас обычно при красивом плане и удаление такое же длинное. особенно приятно, когда через полчаса сервер находит значение, которое не позволяет удалить (каскадов не держим), удаление успешно откатывается, товарищи начинают задаваться вопросом, что с этим делать, может и правда не удалять, проблемное значение оставляют в покое, а через полчаса другое значение вываливается, и снова оно оказывается в нужной строке какой-то еще таблицы, про которую до этого и не вспоминали, а тут вдруг она оказалась необходимой ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 17:51 |
|
|
start [/forum/topic.php?fid=46&msg=40004637&tid=1685583]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 149ms |
0 / 0 |