TGViewer
Сохранёнки программиста Сохранёнки программиста @prog_stuff · 6.53K subscribers
Post #2800 944
Автор этой статьи прогнал JOIN на таблице из миллиарда строк и проверил, насколько оправдан страх перед этой операцией.

Главный вывод: JOIN сам по себе не дорогой. Дорогими его делают конкретные вещи: отсутствие индексов на join-колонках, выбор SELECT * с широкими строками и неправильный порядок фильтрации.

Тезисы из бенчмарка:

— Правильно проиндексированный JOIN на миллиарде строк отрабатывает быстрее, чем денормализованная «One Big Table» при выборке нескольких колонок.

— OBT начинает выигрывать только когда нужно вытащить почти все колонки широкой строки, но это редкий паттерн.

— Главные виновники медленных JOIN-запросов: отсутствие индексов → full scan, CAST() в условии join → план не использует индекс, агрегация после join вместо до него.

Полезно перечитать, если у вас есть коллега, который денормализует всё подряд «ради производительности».

@prog_stuff
  • 👍 2
  • 🤝 2
  • 👎 1
More from @prog_stuff
  1. Sep 21, 2026Как выбрать равновероятную выборку из потока неизвестной длины Интерактивный разбор объясн…
  2. Sep 21, 2026Как LMAX вынесла торговую логику в один поток Разбор архитектуры LMAX показывает, почему м…
  3. Sep 20, 2026Как процессор предсказывает ветвления Псевдотранскрипт доклада объясняет тему с нуля. Конв…
  4. Sep 20, 2026Почему одни движки регулярных выражений зависают, а другие нет Обстоятельная статья Расса…
  5. Sep 19, 2026Как проверять изменения без риска для всего трафика Компактный разбор о снижении риска при…
  6. Sep 19, 2026Как собрать модель пиковой нагрузки из боевой телеметрии Обстоятельный гайд о замене выгру…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →