Какие инструменты для анализа и профилирования SQL-запросов в Go вы знаете?

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

Первое, что надо сделать — это посмотреть, что твоё приложение вообще шлёт в базу. А то пишешь ты там на GORM'e красивый код, а он там какую-то хуйню неоптимальную генерирует, ты даже не в курсе.

Вот, например, в GORM'е это делается элементарно, блядь. Берёшь и включаешь логгер на полную катушку.

db, err := gorm.Open(sqlite.Open("test.db"), &gorm.Config{
  Logger: logger.Default.LogMode(logger.Info), // И он начнёт вываливать все SQL-запросы в консоль, как сумасшедший
})

Смотришь и офигеваешь: "О, ёпта, а зачем он тут SELECT * делает, когда мне нужно только два поля?!" Или "Нахуя он пять джойнов делает, когда можно одним обойтись?". Осознание приходит сразу, поверь.

А если ты работаешь с PostgreSQL через pgx, там тоже не всё потеряно. Настраиваешь логирование, и он тебе всё покажет, с параметрами и прочей хуетой.

config, _ := pgx.ParseConfig("postgres://...")
config.LogLevel = pgx.LogLevelTrace // Включаем режим стукача, блядь

Второй этап — это когда запросы ты уже видишь, но они нихуя не торопятся. Вот тут начинается магия под названием "профилирование". И главный твой друг здесь — не какой-то навороченный инструмент, а простая SQL-команда EXPLAIN ANALYZE. Берёшь свой медленный запрос, подставляешь в неё и запускаешь прямо в БД. Она тебе вывалит план выполнения: какие индексы использовались, сколько строк прошло через каждый этап, где была самая большая задержка. Это, блядь, как рентген для запроса — сразу видно, где кость сломана.

Ну а если ты совсем пафосный и у тебя всё в облаках, то есть сервисы вроде pganalyze или Datadog APM. Они за тебя всё отследят, на красивых графиках покажут, какой запрос — говно, и даже намекнут, что с этим делать. Удобно, но за деньги, естественно.

Третья история — это когда у тебя не монолит, а куча микросервисов. Запрос от пользователя скачет из одного сервиса в другой, каждый что-то своё в базу пилит, и понять, где именно всё встало колом, — это тот ещё квест. Тут на сцену выходит распределённая трассировка, например, через OpenTelemetry. Она как ниточка с иголкой проходит через все твои сервисы и базы, и ты потом на красивом графике видишь: "Ага, 90% времени запрос провёл в этом ебаном методе, который делает запрос без индекса!" Просветление наступает мгновенно.

И наконец, четвёртый пункт — это чтобы вообще не допускать откровенного говнокода. Для этого есть тестирование. Берёшь библиотеку типа go-sqlmock, пишешь юнит-тест и проверяешь: а тот ли запрос генерирует твой код, с теми ли параметрами?

mock.ExpectQuery("^SELECT (.+) FROM users WHERE id = $1").
  WithArgs(1).
  WillReturnRows(rows)

Если что-то пошло не так — тест падает, и ты сразу понимаешь, что накосячил. Это как превентивный удар по собственной жопе, чтобы потом не было мучительно больно в проде.

Короче, суть в чём: не надейся на авось. Смотри, что генерирует твой код, измеряй, где тормозит, тестируй, чтобы не сломалось. А то получится как в той поговорке: "Работает? Не трогай!" А потом ночью разбудят, потому что база легла. И будешь ты сидеть и думать: "И кто же тут, блядь, серит на крыше?".