У меня есть процесс синхронизации мобильного приложения. Транзакция делает большую модификацию на базе данных. Так как это сделано по мобильному телефону, я должен выпустить ВАКУУМ для уплотнения базы данных.
Я задаюсь вопросом, когда должен я выпускать ВАКУУМ
Я в настоящее время ищу SQLite, но если это отличается для других механизмов, сообщите мне в ответах (PostgreSQL, MySQL, Oracle, SQLServer)
Вакуум - это как дефрагментация, это хорошо делать, если вы недавно удалили много вещей, или, может быть, после того, как вы вставили много вещей, но ни в коем случае не следует делать это в каждой транзакции. Это медленнее, чем любая другая команда базы данных, и это скорее задача обслуживания.
Иногда мы добавляем/удаляем большую часть нашего файла базы данных, поэтому вакуум был бы хорошей идеей, но я все равно не стал бы считать его частью той же транзакции, которая выполняла работу.
-121--3572373-Если я правильно вас понимаю, top также не решает вашу проблему. верх в точности эквивалентен пределу. Вы ищете агрегатные функции, такие как max () или min (), если вы хотите крайности. например:
select link_id, max(column_a), min(column_b) from table_a a, table_b b
where a.link_id = b.link_id group by link_id
-121--5086087- Я бы сказал, вне транзакции. Конечно, в PostgreSQL, VACUUM предназначен для удаления «мертвых» кортежей (то есть старой строки, когда запись была изменена или удалена.)
Если вы используете VACUUM в транзакции, которая изменила записи, эти мертвые строки не будут помечены для удаления.
В зависимости от того, какой тип VACUUM вы делаете, может также потребоваться блокировка таблицы, которая заблокирует, если выполняются другие транзакции, так что вы можете оказаться в ситуации взаимоблокировки (транзакция 1 блокируется в ожидании блокировки таблицы для выполнения команды VACUUM, транзакция 2 блокируется в ожидании освобождения строки, заблокированной транзакцией 1.)
Я бы также рекомендовал, чтобы это не делалось в приложении (возможно, в качестве запланированной задачи), поскольку это может занять некоторое время и негативно повлиять на скорость других запросов.
Что касается SQL Server, то здесь нет VACUUM - то, что вы ищете, это сокращение. Вы можете включить автоматическое сжатие в 2005 году, которое автоматически освободит место, когда сервер решит, или выдать инструкцию DBCC для сжатия базы данных и файла журнала, но это зависит от вашей процедуры резервного копирования и стратегии на уровне базы данных.
Хотите вы того или нет, при использовании PostgreSQL вы не можете запустить VACUUM в транзакции, как сказано в руководстве :
VACUUM не может быть выполнен внутри блока транзакции.
Как часто выполняется транзакция?
Это действительно ежедневный процесс, а не процесс запроса за запросом, но если вы используете его не полностью, то его можно использовать в транзакции, поскольку он не приобретает блокировку.
Если вы собираетесь это делать, то это должно быть вне транзакции, поскольку это не зависит от целостности данных транзакции.
Вакуум похож на дефрагментацию, это полезно делать, если вы недавно удалили много чего или, может быть, после того, как много чего вставили, но ни в коем случае не должны делать это в каждой транзакции. Это медленнее, чем почти любая другая команда базы данных, и требует больше обслуживания.
Иногда мы добавляем / удаляем большую часть нашего файла db, поэтому вакуум будет хорошей идеей, но я все равно не считаю его частью той же транзакции, которая выполняла работу.