Какие основные методы оптимизации производительности баз данных?

А, оптимизация баз данных, говоришь? Ну это же святое, блядь! Это как под капотом у тачки ковыряться — можно всё разъебать к хуям, если не знать, куда совать свои кривые ручонки. Но если подойти с умом, то эта штука из жопного ведра, которое тормозит на каждом чихе, превращается в реактивный самолёт. Слушай сюда, сейчас разжую.

Индексация — это вообще основа основ, ёпта. Без индексов твоя база данных будет искать данные, как слепой кот в подвале — методом научного тыка, по всей таблице. А это, на минуточку, операция за O(n), что в переводе на русский означает «хуёво и медленно».

Вот смотри, как красивый индекс делается:

-- Создание составного индекса
CREATE INDEX idx_user_email_active 
ON users(email, is_active) 
WHERE is_active = true; -- Частичный индекс в PostgreSQL

Видишь эту приписку WHERE? Это гениально, блядь! Мы говорим базе: «Слушай, дорогой, индексируй только активных юзеров, а на этих неактивных бомжей забей болт, они нам неинтересны». Экономия места и скорости — овердохуищная.

А в нашем любимом Hibernate это выглядит так, будто мы наряжаем ёлку:

@Entity
@Table(indexes = {
    @Index(name = "idx_email", columnList = "email", unique = true),
    @Index(name = "idx_status_created", columnList = "status, created_at")
})
public class User {
    @Id
    private Long id;
    private String email;
    private String status;
    private LocalDateTime createdAt;
}

Навешали индексов прямо на сущность, красота! Главное — не переборщить, а то каждая вставка будет как похороны: долго, муторно и все плачут.

Дальше идёт оптимизация запросов. Вот тут-то и сидит главный враг человечества — N+1 проблема. Представь: ты получаешь список заказов, а потом для КАЖДОГО заказа отдельным запросом дергаешь его позиции. Это пиздец, Карл! Это как сходить в магазин за хлебом, а потом отдельно — за маслом, отдельно — за колбасой, и так двадцать раз.

// Плохо: N+1 запрос. Делай так — и тебя уволят.
List<Order> orders = entityManager.createQuery(
    "SELECT o FROM Order o", Order.class).getResultList();
// Для каждого order: order.getItems() — отдельный запрос. Охуеть можно.

Решение проще, чем кажется — надо сразу всё забрать одним махом, как умный человек:

// Решение: JOIN FETCH. Всё за один раз, красиво и без нервов.
List<Order> orders = entityManager.createQuery(
    "SELECT DISTINCT o FROM Order o JOIN FETCH o.items", 
    Order.class).getResultList();

И всегда смотри план выполнения (EXPLAIN ANALYZE), это как рентген для твоего запроса. Увидишь, где он делает лишние телодвижения, и поймёшь, куда дать под зад.

Кэширование — это волшебная таблетка от повторяющейся боли. Зачем десять раз спрашивать у базы одно и то же, если можно спросить один раз и запомнить ответ? Уровней кэша дохуя: можно кэшировать в Redis на уровне всего приложения, а можно заставить Hibernate кэшировать результаты запросов или сами сущности. Включается это вот такой магией в persistence.xml:

<!-- persistence.xml -->
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.region.factory_class" 
          value="org.hibernate.cache.ehcache.EhCacheRegionFactory"/>

После этого Hibernate начинает меньше дёргать базу, а ты — меньше пить валерьянку.

Настройка пула соединений — это про то, чтобы не создавать новое подключение к базе каждый раз, когда тебе что-то нужно. Это жесть, блядь, это очень дорого! Используй HikariCP, настрой его правильно, и он будет держать несколько готовых соединений, как такси на стоянке.

# application.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000

Не делай пул на 500 соединений, если у тебя 2 пользователя. Это как купить автобус, чтобы в одиночку на работу ездить.

И наконец, мониторинг. Без него ты слепой. Ты должен знать, какие запросы тормозят, какой процент попаданий в кэш, нет ли диких блокировок. Настрой Prometheus + Grafana, подключи pg_stat_statements для Постгреса. Алгоритм простой, как три копейки: 1) Замеряешь, где сейчас больно. 2) Находишь конкретную причину, этот узкий горлышко. 3) Пытаешься его расширить (индексом, кэшем, переписыванием запроса). 4) Снова замеряешь — помогло или нет? Если нет — начинаешь с пункта 1, предварительно выругавшись матом.

Вот и вся наука. Не так страшен чёрт, как его малюют. Главное — не бояться, смотреть на цифры и не делать глупостей вроде SELECT * без WHERE на таблице в миллиард строк. Удачи, и да пребудет с тобой низкая латенси!