Может ли DELETE удалить всю таблицу?

DELETE в SQL: может ли удалить всю таблицу?

Это критически важный вопрос о понимании SQL синтаксиса, опасности и safeguards в production. Требует знания как правильной синтаксиса, так и защитных механизмов.

Короткий ответ: ДА, может

-- ✅ Этот запрос удалит ВСЕ строки из таблицы
DELETE FROM users;
-- Результат: 1,000,000 строк удалено
-- Таблица структура остаётся, но данные ушли

Разница между DELETE и DROP

-- DELETE: удаляет ДАННЫЕ (строки)
DELETE FROM users;  -- удаляет ВСЕ строки
DELETE FROM users WHERE id = 123;  -- удаляет ОДНУ строку
-- Структура таблицы ОСТАЁТСЯ
-- Можно откатить с ROLLBACK (если в транзакции)

-- DROP: удаляет ТАБЛИЦУ (структура + данные)
DROP TABLE users;  -- удаляет ВСЮ таблицу вместе с индексами
-- Структура УХОДИТ
-- Полное удаление (даже внутри TRANSACTION)

Пример DELETE без WHERE

-- ❌ ОПАСНО! Удалит все 5 миллионов строк
DELETE FROM orders;  -- Без WHERE условия

-- Как это произойдёт:
SELECT COUNT(*) FROM orders;  -- 5,000,000 rows
DELETE FROM orders;            -- BOOM!
SELECT COUNT(*) FROM orders;  -- 0 rows

-- ✅ ПРАВИЛЬНО: с WHERE условием
DELETE FROM orders WHERE status = 'archived';
DELETE FROM orders WHERE created_at < '2020-01-01';
DELETE FROM orders WHERE id = 123;

Реальная история: инцидент на продакшене

2024-03-20 14:32 UTC
Prod incident: Someone ran
  DELETE FROM users WHERE updated_at > '2024-03-20';

Проблема: оператор > вместо <
  Результат: 50,000 активных пользователей удалено
  Время восстановления: 2 часа
  Потери: $50,000 в упущенной выручке
  Репутация: повреждена

Причина: отсутствие safeguards

Почему DELETE может удалить всю таблицу

Сценарий 1: Опечатка в WHERE

-- ❌ Хотел удалить старые заказы
DELETE FROM orders WHERE id > 100;  -- Оператор > вместо <
-- Результат: удалены все заказы с id > 100 (99% таблицы)

-- ❌ Плохой CAST
DELETE FROM orders WHERE created_at > CAST('2024-03-20' AS TIMESTAMP);
-- Если это будущая дата: удалит всё

-- ❌ Опечатка в названии колонки
DELETE FROM orders WHERE createdAT > '2024-01-01';  -- typo!
-- Может привести к неправильному условию

Сценарий 2: Забыл WHERE условие

public class UserRepository {
    public void deleteExpiredUsers(LocalDate expireDate) {
        // ❌ КРИТИЧЕСКАЯ ОШИБКА
        entityManager.createQuery(
            "DELETE FROM User u"
            // ЗАБЫЛИ WHERE u.expiryDate < :date
        ).executeUpdate();  // Удалит ВСЕ пользователей!
        
        // ✅ ПРАВИЛЬНО
        entityManager.createQuery(
            "DELETE FROM User u WHERE u.expiryDate < :date"
        ).setParameter("date", expireDate)
         .executeUpdate();
    }
}

Сценарий 3: Логическая ошибка в условии

-- ❌ Хотел удалить активных пользователей старше 1 года
-- но условие работает в обратную сторону
DELETE FROM users 
WHERE is_active = true 
  AND created_at > DATE_SUB(NOW(), INTERVAL 1 YEAR);
-- Результат: удалены ВСЕ активные пользователи!

-- ✅ ПРАВИЛЬНО
DELETE FROM users 
WHERE is_active = true 
  AND created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

Защитные механизмы в production

1. Soft Delete вместо DELETE

// ✅ Безопаснее всего: никогда не удаляй, помечай
@Entity
@Table(name = "users")
public class User {
    @Id
    private UUID id;
    
    private String name;
    
    @Column(nullable = true)
    private LocalDateTime deletedAt;  // ← Мягкое удаление
    
    // При "удалении" просто заполняем это поле
}

// В SQL:
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMPTZ DEFAULT NULL;

// Вместо DELETE:
UPDATE users SET deleted_at = NOW() WHERE id = 123;

// При SELECT:
SELECT * FROM users WHERE deleted_at IS NULL;

// Преимущества:
// - Можно восстановить данные
// - Сохраняется история
// - Можно видеть кто и когда удалил

2. Database Constraints

-- Запретить DELETE без WHERE
-- (К сожалению, это невозможно в SQL стандарте,
--  но можно сделать через TRIGGER)

CREATE TRIGGER prevent_full_delete
BEFORE DELETE ON users
FOR EACH STATEMENT
BEGIN
    IF (SELECT COUNT(*) FROM users) = (
        SELECT COUNT(*) FROM users WHERE deleted_at IS NOT NULL
    ) THEN
        RAISE EXCEPTION 'Full table delete attempt detected!';
    END IF;
END;

3. Application-Level Protection

@Repository
public class SafeUserRepository {
    @PersistenceContext
    private EntityManager em;
    
    // ❌ НЕ ДОПУСКАЕМ безусловное удаление
    @Deprecated(forRemoval = true)
    public void deleteAllUsers() {
        throw new UnsupportedOperationException(
            "Full table delete is forbidden! Use soft delete instead.");
    }
    
    // ✅ Только удаление с условием
    public void deleteUsersByStatus(UserStatus status) {
        if (status == null) {
            throw new IllegalArgumentException("Status cannot be null");
        }
        
        int deleted = em.createQuery(
            "DELETE FROM User u WHERE u.status = :status")
            .setParameter("status", status)
            .executeUpdate();
        
        if (deleted > 10000) {
            log.warn("Large DELETE operation: {} rows deleted", deleted);
        }
    }
}

4. Database-Level Controls (PostgreSQL)

-- Создать специальный пользователь БД без прав на DELETE
CREATE ROLE app_user WITH LOGIN PASSWORD 'secure_password';

-- Дать только SELECT, INSERT, UPDATE
GRANT SELECT, INSERT, UPDATE ON users TO app_user;
-- НЕ дать DELETE и DROP

-- Лог всех DELETE операций
CREATE AUDIT_LOG TABLE для отслеживания

-- Row-level security
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
CREATE POLICY user_isolation ON users
    USING (user_id = current_user_id);

5. Pre-Delete Checks в коде

public class DeleteValidationService {
    
    public void safeDelete(Class<?> entityClass, 
                          Predicate<Long> whereCondition) {
        
        // Шаг 1: Подсчитаем сколько будет удалено
        long countToDelete = countMatching(entityClass, whereCondition);
        
        // Шаг 2: Проверим соотношение
        long totalCount = countTotal(entityClass);
        double percentage = (countToDelete / totalCount) * 100;
        
        if (percentage > 50) {
            // ⚠️ Подозрительно!
            log.warn("Deleting {}% of table {}", 
                     percentage, entityClass.getSimpleName());
            throw new DeletionThresholdExceededException(
                "Cannot delete more than 50% in one operation");
        }
        
        // Шаг 3: Требуем явное подтверждение
        if (countToDelete > 1000) {
            throw new ConfirmationRequiredException(
                "This operation will delete " + countToDelete + 
                " rows. Require explicit confirmation.");
        }
        
        // Шаг 4: Логируем
        auditLog.recordDeletion(entityClass, countToDelete);
        
        // Шаг 5: Удаляем
        performDelete(entityClass, whereCondition);
    }
}

Best Practices для DELETE

-- ✅ ВСЕГДА используй WHERE
DELETE FROM orders WHERE id = 123;
DELETE FROM orders WHERE status = 'cancelled';
DELETE FROM orders WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

-- ✅ ВСЕГДА сначала SELECT
-- Перед DELETE всегда проверь что удаляешь
SELECT COUNT(*) FROM orders WHERE status = 'cancelled';  -- 150 rows
DELETE FROM orders WHERE status = 'cancelled';

-- ✅ Используй LIMIT для больших таблиц
DELETE FROM logs WHERE created_at < '2024-01-01' LIMIT 10000;
-- Потом запусти ещё раз для остальных

-- ✅ Используй транзакции
BEGIN TRANSACTION;
DELETE FROM orders WHERE status = 'cancelled';
-- Проверь результат
ROLLBACK;  -- или COMMIT

-- ✅ Заархивируй перед удалением
CREATE TABLE orders_archived AS 
  SELECT * FROM orders WHERE created_at < '2020-01-01';
DELETE FROM orders WHERE created_at < '2020-01-01';

Восстановление после полного DELETE

# Если случилось беда:

# 1. СРАЗУ остановить приложение (минимизировать новые изменения)
# 2. Создать снимок (snapshot) текущей БД
# 3. Запросить backup
# 4. Восстановить из backup на отдельный сервер
# 5. Синхронизировать данные
# 6. Post-mortem анализ

# Команда восстановления:
psql -h backup-server -U postgres < /backup/2024-03-20.sql

Заключение

Да, DELETE может удалить всю таблицу:

DELETE FROM table_name;  -- Удалит ВСЕ строки

Защита:

1. ✅ Soft delete (update deleted_at, не DELETE)
2. ✅ WHERE условие ВСЕГДА обязательно
3. ✅ Pre-check: SELECT перед DELETE
4. ✅ Permissions: ограничить права на DELETE
5. ✅ Audit logging: логировать все DELETE операции
6. ✅ Monitoring: алерты при большом DELETE
7. ✅ Backup: регулярные резервные копии
8. ✅ Code review: проверять все DELETE запросы

Золотое правило:

"Никогда не пиши DELETE без WHERE условия.
Если собираешься удалить всё — используй архивирование и soft delete."