Какие ошибки делают команды, когда прячут сложность базы данных за Hibernate?

Ошибка 1: Игнорирование N+1 до продакшна

Разработчики создают удобные связи через @OneToMany и получают объектный граф, не думая о SQL. В dev-среде с 10 записями всё работает. В продакшн с 10 000 — деградация под нагрузкой.

// Проблемный код: N+1 на каждую категорию
List<Category> categories = categoryRepo.findAll(); // 1 SELECT
for (Category cat : categories) {
    cat.getProducts().size(); // N SELECT — по одному на категорию
}

// Правильно: JOIN FETCH
List<Category> categories = em.createQuery(
    "SELECT c FROM Category c JOIN FETCH c.products",
    Category.class
).getResultList();

Ошибки при скрытии сложности базы данных за Hibernate

Hibernate позволяет работать с данными как с объектами, но это абстракция с утечками. Команды, которые воспринимают Hibernate как полную замену знаний о базе данных, регулярно сталкиваются с предсказуемыми проблемами.

Ошибка 2: Отсутствие знаний об индексах

Команды добавляют @Column, @ManyToOne и ожидают, что Hibernate создаст оптимальную схему. Но Hibernate не добавляет индексы автоматически на foreign key колонки (кроме некоторых диалектов). Запросы по user_id без индекса делают Seq Scan.

// Явно указываем индексы в аннотации
@Table(
    name = "orders",
    indexes = {
        @Index(name = "idx_orders_user_id", columnList = "user_id"),
        @Index(name = "idx_orders_created_at", columnList = "created_at")
    }
)
@Entity
public class Order { ... }

Ошибка 3: Доверие hbm2ddl.auto в продакшне

Настройка hbm2ddl.auto=update привлекательна — схема меняется автоматически при деплое. На практике это молчаливое переименование колонок (DROP + ADD = потеря данных), неконтролируемые ALTER TABLE в рабочей базе.

# Правильно для продакшна
spring:
  jpa:
    hibernate:
      ddl-auto: validate  # только проверка соответствия, без изменений
# Миграции через Liquibase или Flyway — явно и версионированно

Ошибка 4: Бизнес-логика в lazy-коллекциях

Когда метод сервиса возвращает entity с ленивыми коллекциями, а контроллер или DTO-маппер обращается к ним вне транзакции — LazyInitializationException. Это признак того, что граница транзакции и граница сессии не совпадают.

// Плохо: entity возвращается из @Transactional метода,
// сессия закрывается, контроллер обращается к lazy полю
@GetMapping("/users/{id}")
public UserDto getUser(@PathVariable Long id) {
    User user = userService.findById(id);
    user.getOrders().size(); // LazyInitializationException!
    ...
}

// Правильно: загружать всё нужное внутри транзакции или использовать DTO-проекцию

Ошибка 5: Массовые операции через ORM

Обновление 100 000 записей через findAll() + цикл — это загрузка всех объектов в память, dirty checking каждого, 100 000 отдельных UPDATE. Массовые операции должны идти напрямую через SQL.

// Плохо: 100k объектов в памяти
List<User> users = userRepo.findAll();
users.forEach(u -> u.setActive(false));
// flush: 100k UPDATE запросов

// Правильно: один UPDATE
@Modifying
@Query("UPDATE User u SET u.active = false WHERE u.createdAt < :date")
void deactivateOldUsers(@Param("date") LocalDate date);

Ошибка 6: Игнорирование connection pool

Hibernate работает поверх пула соединений (HikariCP по умолчанию). Длинные транзакции, Open Session in View, вызовы внешних API внутри транзакции — всё это держит соединения из пула, приводя к исчерпанию под нагрузкой.

Подводные камни

• FetchType.EAGER на @OneToMany — Hibernate делает JOIN при каждой загрузке сущности, даже когда коллекция не нужна
• Каскадное удаление (CascadeType.REMOVE) на большой коллекции — загружает все дочерние объекты перед удалением вместо одного DELETE
• orphanRemoval = true без понимания — удаление элемента из Java-коллекции удаляет запись из БД
• Использование entity как DTO в REST API — изменения поля в JSON-ответе клиента могут стать managed-изменениями при десериализации
• Отсутствие @Version при конкурентных обновлениях — потерянные обновления (lost update) без явных блокировок
• Транзакции @Transactional на private методах — Spring AOP не перехватывает их, транзакция не создаётся
• Hibernate кеш второго уровня без инвалидации при прямых SQL-операциях — кеш показывает устаревшие данные
• Ленивые коллекции в многопоточном коде (async @Scheduled) — сессия не thread-safe, NPE или LazyInitializationException

• Перечислять ошибки без объяснения причин
• Не отличать beginner mistakes от production failure modes
• Не предлагать процесс, который предотвращает повторение ошибок

• Знает типичные ошибки при работе с Hibernate
• Понимает причины ошибок
• Предлагает практики prevention и early detection