TRUNCATE и DELETE в SQL: чем отличаются и как очистить таблицу

TRUNCATE в SQL очищает таблицу целиком одной командой: TRUNCATE TABLE orders; Строки исчезают, а сама таблица, её столбцы, индексы и права остаются на месте. DELETE делает похожую работу иначе: удаляет строки по условию WHERE, проходит по ним по одной и вызывает триггеры.

Если нужно удалить часть записей, берите DELETE. Если нужна пустая таблица и никто, кроме вас, с ней сейчас не работает, быстрее TRUNCATE. Ниже синтаксис для пяти СУБД, сравнение по восьми пунктам и замер скорости на миллионе строк. Если вы только начинаете с запросами, сначала прочитайте что такое язык SQL.

CheckroiПодборка курсов по SQL422 курса • 40 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→

Синтаксис TRUNCATE в PostgreSQL, MySQL, SQL Server и Oracle

Базовая форма одинакова почти везде:

TRUNCATE TABLE имя_таблицы;

Отличаются дополнительные параметры и одна СУБД, где команды нет вовсе.

В SQLite запрос TRUNCATE TABLE orders; падает с ошибкой near "TRUNCATE": syntax error. Быстрый режим для DELETE без условия описан в разделе The Truncate Optimization документации SQLite.

Для примеров дальше нужна таблица заказов. Если вы ещё не создавали свою базу, посмотрите, как создать базу данных в SQL.

Чем TRUNCATE отличается от DELETE

Обе команды могут оставить таблицу пустой, но устроены по-разному. DELETE работает со строками, а TRUNCATE со всей таблицей сразу. Отсюда все остальные различия.

Про триггеры, блокировку и внешние ключи в PostgreSQL написано в разделе «Примечания» описания команды TRUNCATE. Для MySQL то же самое собрано в справке TRUNCATE TABLE: там прямо сказано, что «0 rows affected» значит «нет информации», а не ноль удалённых строк. Точное число строк до очистки удобно узнать функцией COUNT.

Что быстрее: замер на миллионе строк

Мы заполнили две одинаковые таблицы миллионом строк (числовой ключ и короткий текст), одну очистили через DELETE без условия, другую через TRUNCATE. Каждую пару запускали трижды на обычном ноутбуке.

Разница в десятки и сотни раз появляется потому, что DELETE проходит по каждой строке и записывает её удаление в журнал, а TRUNCATE просто освобождает место, занятое таблицей. Чем больше строк и индексов, тем заметнее разрыв. На таблице из сотни записей вы его не увидите.

У PostgreSQL время DELETE заметно менялось от прогона к прогону, а у TRUNCATE почти нет.

Сбрасывает ли TRUNCATE счётчик id

Зависит от СУБД, и здесь легче всего ошибиться.

PostgreSQL: по умолчанию не сбрасывает

CREATE TABLE orders (
  id      serial PRIMARY KEY,
  client  text,
  status  text
);
INSERT INTO orders (client, status) VALUES
  ('Анна', 'paid'), ('Борис', 'cancelled'), ('Вера', 'paid');

TRUNCATE TABLE orders;
INSERT INTO orders (client, status) VALUES ('Глеб', 'paid');
SELECT * FROM orders;
 id | client | status
----+--------+--------
  4 | Глеб   | paid

TRUNCATE TABLE orders RESTART IDENTITY;
INSERT INTO orders (client, status) VALUES ('Дина', 'paid');
SELECT * FROM orders;
 id | client | status
----+--------+--------
  1 | Дина   | paid

Без параметра действует CONTINUE IDENTITY. Документация PostgreSQL называет его поведением по умолчанию: последовательность не меняется, и новые строки продолжают нумерацию. Как устроены serial, IDENTITY и последовательности, разбирают на курсах по PostgreSQL.

MySQL и SQL Server: сбрасывают

В MySQL после TRUNCATE AUTO_INCREMENT возвращается к началу, а после DELETE нет:

DELETE FROM orders;
INSERT INTO orders (client, status) VALUES ('Глеб', 'paid');
SELECT * FROM orders;
+----+--------+--------+
| id | client | status |
+----+--------+--------+
|  4 | Глеб   | paid   |
+----+--------+--------+

TRUNCATE TABLE orders;
INSERT INTO orders (client, status) VALUES ('Дина', 'paid');
SELECT * FROM orders;
+----+--------+--------+
| id | client | status |
+----+--------+--------+
|  1 | Дина   | paid   |
+----+--------+--------+

SQL Server ведёт себя так же. По справке Microsoft, счётчик столбца IDENTITY возвращается к начальному значению, а если оно не задано, к единице. Чтобы сохранить нумерацию, Microsoft советует DELETE.

Можно ли откатить TRUNCATE

В PostgreSQL можно. Очистка внутри транзакции отменяется так же, как обычный DELETE:

BEGIN;
TRUNCATE TABLE orders;
SELECT count(*) FROM orders;
 count
-------
     0

ROLLBACK;
SELECT count(*) FROM orders;
 count
-------
     3

В MySQL тот же сценарий не работает. TRUNCATE вызывает неявный COMMIT, поэтому после ROLLBACK таблица остаётся пустой:

START TRANSACTION;
TRUNCATE TABLE orders;
ROLLBACK;
SELECT count(*) FROM orders;
+----------+
| count(*) |
+----------+
|        0 |
+----------+

• SQL Server откатывает TRUNCATE внутри транзакции, в справке Microsoft это пример C «Откат операции усечения».
• Oracle не откатывает и не даёт вернуть данные через FLASHBACK TABLE, об этом сказано в документации Oracle.

Если вы не уверены, в какой СУБД работаете, считайте TRUNCATE необратимым и делайте копию таблицы заранее. Версию сервера видно в свойствах подключения любого клиента, например DBeaver.

TRUNCATE и внешние ключи

Добавим таблицу позиций заказа, которая ссылается на orders. Даже когда в ней нет ни одной строки, PostgreSQL откажется чистить родительскую таблицу:

TRUNCATE TABLE orders;
ERROR:  cannot truncate a table referenced in a foreign key constraint
DETAIL:  Table "items" references "orders".
HINT:  Truncate table "items" at the same time, or use TRUNCATE ... CASCADE.

Решение: перечислить обе таблицы в одной команде (TRUNCATE orders, items;) или добавить CASCADE. Второй вариант очистит все таблицы, которые ссылаются на orders, поэтому сначала проверьте, какие это таблицы.

MySQL возвращает ошибку 1701:

ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint (`shop`.`items`, CONSTRAINT `items_ibfk_1`)

CASCADE в MySQL нет. Остаётся DELETE, который пройдёт, если ссылающихся строк нет, или очистка с выключенной проверкой ключей: SET FOREIGN_KEY_CHECKS = 0; перед TRUNCATE и SET FOREIGN_KEY_CHECKS = 1; после. Тогда за целостность связей отвечаете вы: строки в items останутся ссылаться на несуществующие заказы. SQL Server тоже не даёт очищать таблицу, на которую ссылается FOREIGN KEY. Как таблицы связываются между собой, разобрано в статье про JOIN в SQL.

Канал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 700 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в канал→

DELETE, TRUNCATE или DROP: что выбрать

• Удалить часть строк, например отменённые заказы или записи старше года. Здесь подходит только DELETE с WHERE.
• Очистить таблицу перед новой загрузкой: тестовые данные, промежуточную таблицу для выгрузки. Берите TRUNCATE.
• Очистить таблицу с триггерами аудита. Нужен DELETE, иначе журнал удалений останется пустым.
• Убрать таблицу совсем вместе со структурой поможет DROP TABLE. После него запрос к таблице вернёт ошибку, её придётся создавать заново.

Частые ошибки

DELETE без WHERE на рабочей базе

Запрос DELETE FROM orders; синтаксически верен, и СУБД выполнит его без предупреждения.

Решение: сначала запустите SELECT с тем же условием и посмотрите, что попадёт под удаление. Потом выполните DELETE внутри транзакции и подтвердите COMMIT, только если число удалённых строк совпало.

TRUNCATE на таблице, с которой работают другие

В PostgreSQL TRUNCATE берёт блокировку ACCESS EXCLUSIVE. Пока блокировка не снята, к таблице не пройдёт даже чтение, а сама команда будет ждать завершения чужих запросов.

Решение: чистить такие таблицы, когда нагрузка минимальна, например ночью, или удалять строки через DELETE порциями.

Ожидание, что id начнутся с единицы

В PostgreSQL после обычного TRUNCATE нумерация продолжится с последнего значения. Если код или тесты рассчитывают на id = 1, добавьте RESTART IDENTITY.

Проверка по числу удалённых строк в MySQL

Скрипт, который проверяет результат по «rows affected», после TRUNCATE увидит 0 и решит, что ничего не удалилось. Проверяйте результат запросом SELECT count(*).

Где освоить SQL системно

Разница между TRUNCATE и DELETE упирается в транзакции, блокировки и внешние ключи. Эти темы, а ещё оптимизацию запросов, подробно разбирают на курсах SQL. Подборка ниже собрана из каталога Checkroi, а если вы думаете о профессии, начните с плана, как стать SQL-разработчиком.

Курс	Школа	Стоимость со скидкой	В рассрочку	Длитель­ность	Обзор курса от Checkroi
Нейросети для рабочих задач Перейти на сайт курса	Skillbox	31 290 ₽	-	1 месяц	Обзор курса
SQL для анализа данных Перейти на сайт курса	Skillbox	52 353 ₽	6203 ₽/мес.	2 месяца	Обзор курса
SQL-разработчик: тариф PRO Перейти на сайт курса	Эдюсон	89 900 ₽	7491 ₽/мес.	2 месяца	Обзор курса
SQL-разработчик: тариф Базовый Перейти на сайт курса	Эдюсон	79 900 ₽	3329 ₽/мес.	3 месяца	Обзор курса
SQL с нуля	Skypro	134 640 ₽	5500 ₽/мес.	12 месяцев	Обзор курса

• 

  Нейросети для рабочих задач

  Skillbox31 290 ₽1 месяц
  Перейти на сайт курсаОбзор
• 

  SQL для анализа данных

  Skillbox52 353 ₽6203 ₽/мес2 месяца
  Перейти на сайт курсаОбзор
• 

  SQL-разработчик: тариф PRO

  Эдюсон89 900 ₽7491 ₽/мес2 месяца
  Перейти на сайт курсаОбзор
• 

  SQL-разработчик: тариф Базовый

  Эдюсон79 900 ₽3329 ₽/мес3 месяца
  Перейти на сайт курсаОбзор
• 

  SQL с нуля

  Skypro134 640 ₽5500 ₽/мес12 месяцев
  Обзор

Больше программ — в полном каталоге курсов по SQL