|
|
|
Долгая выборка после очистки таблицы
|
|||
|---|---|---|---|
|
#18+
Firebird 3.0.2 on Windows Server 2012 БД ~900Гб Таблица ~100 млн записей по 14б, из индексов только первичный ключ. Делаю без условий Код: sql 1. Сама по себе эта операция занимает несколько секунд. Но далее первый Код: sql 1. затягивается более, чем на полчаса. Что, собственно, происходит, удаляется мусор этой таблицы? Сравнение номеров версий, все такое... А нельзя ли его удалить как-нибудь э... разом, что ли. Если есть понимание, что таблица-то пуста на самом деле. И будет ли быстрее очистка через drop table - create table? База слишком тяжелая и времена слишком велики для экспериментов, хотелось бы сперва получить теоретическое представление. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2020, 20:21 |
|
||
|
Долгая выборка после очистки таблицы
|
|||
|---|---|---|---|
|
#18+
shalamyansky, drop table может и не получиться, если есть зависимости (ссылки на табличку). А вообще, местные власти за частые drop/create/alter сильно ругаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2020, 20:59 |
|
||
|
Долгая выборка после очистки таблицы
|
|||
|---|---|---|---|
|
#18+
Удаление 100М записей за несколько секунд - в это конечно можно поверить, например если несколько - это несколько десятков, или сотен... Насчёт долгого первого селекта. Мы не знаем, сколько там было бекверсий у каждой записи. Если бы их не было вовсе, то сборка мусора в таблице без индексов выполняется несколько быстрее, чем удаление записей. Если операция одноразовая, то: если нет зависимостей - проще всего сделать recreate (drop + create), если есть зависимости и с ними неохота возиться - дроп индексов, селект со сборкой мусора, воссоздание индексов. Каждый этап со своим коммитом. Если операция регулярная, то нужно править консерваторию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2020, 21:05 |
|
||
|
Долгая выборка после очистки таблицы
|
|||
|---|---|---|---|
|
#18+
hvlad Удаление 100М записей за несколько секунд - в это конечно можно поверить На самом деле там были минуты, это я от плохой памяти и для красного словца. Но суть, что select был на порядок дольше, чем delete, и долог был весьма. hvlad дроп индексов, селект со сборкой мусора,воссоздание индексов Этот вариант я не видел, да, надо будет попробовать, спасибо. Операция спорадическая, но все же хочется управляться с ней побыстрее. И почему бы серверу не взять эти заботы (дроп индекса, восстановление индекса и пр.) на себя, если он видит при commit на full delete, что нужна в результате только пустая таблица? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2020, 23:30 |
|
||
|
Долгая выборка после очистки таблицы
|
|||
|---|---|---|---|
|
#18+
shalamyansky если он видит при commit на full delete Ибо есть и другие коннекты, которые могут не только писать параллельно удалению, но и читать позапрошлогодние данные. И вообще - удалённое станет мусором не в момент коммита, а позже. Иногда сильно позже. Для быстрой очистки есть свой инструмент - TRUNCATE, об этом нужно говорить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2020, 01:39 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=39942355&tid=1560400]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
126ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 240ms |
| 0 / 0 |
