Индексирование

Индекс — это как предметный указатель в конце книги: он позволяет базе данных сразу перейти к совпадающим строкам вместо сканирования каждой. Без индексов запросы становятся медленнее по мере роста данных — нормально на 100 строках, мучительно на 1 000 000.

Без индекса база данных проверяет каждую строку по очереди; с индексом она прыгает прямо к совпадениям — так же, как предметный указатель в книге отправляет вас на нужную страницу, а не заставляет читать от корки до корки:

  NO INDEX  (Seq Scan)              WITH INDEX  (Index Scan)
  читать КАЖДУЮ row подряд          прыжок прямо к совпадениям
  ┌─────────────────────┐          ┌─────────────┐
  │ row 1   ✗           │          │   INDEX     │
  │ row 2   ✗           │          │ author_id   │
  │ row 3   ✓  совп.     │  ◀──────┐ │   ──┬──     │
  │ row 4   ✗           │         │ └─────┼───────┘
  │ ...     (1,000,000) │         │       ▼
  │ row N   ✓  совп.     │         └──▶ rows 3, 998   ✓
  └─────────────────────┘          пара переходов, а не миллион

Практическое руководство:

• Индексируйте столбцы, по которым вы часто фильтруете или соединяете (например, author_id, email).
• Первичные ключи индексируются автоматически.
• Не индексируйте всё подряд — каждый индекс ускоряет чтение, но замедляет запись и занимает место.
• Добавляйте индексы, когда видите медленный запрос, а не превентивно для каждого столбца.

Честный способ выяснить, помогает ли индекс, — спросить базу данных, а не гадать. У каждого SQL-движка есть EXPLAIN (в Postgres — EXPLAIN ANALYZE), который показывает план, который он применит:

EXPLAIN ANALYZE
SELECT * FROM posts WHERE author_id = '...';

Если на большой таблице вывод говорит Seq Scan, база данных читает каждую строку — признак того, что индекс помог бы. После его добавления он должен переключиться на Index Scan. Это отличная задача, чтобы передать AI: вставьте медленный запрос и вывод EXPLAIN и спросите, какой индекс добавить и почему. Вы сохраняете контроль, понимая ответ, а не заучивая теорию индексов.