Напиши SQL запрос для выбора всех чатов пользователя с именем Вася

Что проверяют

Соединение таблиц и, что важнее, готовность спросить про схему. Для бэкендера на Go вопрос почти всегда продолжается в код: как параметр попадает в запрос, как читается результат и что будет, если пользователей с таким именем окажется двое.

Как отвечать

Скажите, что ответ зависит от связи. Если чат принадлежит одному владельцу, хватает одного соединения, но обычно у чата есть участники, и это связь многие ко многим через таблицу членства:

SELECT DISTINCT c.id, c.title
FROM chats c
JOIN chat_members m ON m.chat_id = c.id
JOIN users u ON u.id = m.user_id
WHERE u.name = 'Вася';

Сразу добавьте, что имя это не идентификатор. Искать правильнее по u.id, а по имени только если так просили. Если тёзки возможны, запрос вернёт чаты всех Вась сразу, и об этом надо предупредить самому.

Вторая половина ответа про Go. Значение подставляется плейсхолдером, а не форматированием строки. Запрос выполняется через QueryContext с таймаутом, rows закрывается через defer, а после цикла обязательно проверяется rows.Err(), иначе оборванное чтение выглядит как пустая выдача.

Где спотыкаются

Склеивают имя в текст запроса через fmt.Sprintf. Это инъекция, и она перечёркивает правильный SQL целиком. Плейсхолдеры отличаются по диалекту, и это нормальный повод уточнить, какой драйвер используется в проекте.

Считают связь один ко многим, не спросив. Запрос тогда молча теряет групповые чаты, где пользователь участник, а не создатель. В обратную сторону бывает хуже: соединение по членству без DISTINCT вернёт один чат столько раз, сколько у него подходящих строк участия.

Пишут SELECT * и сканируют в фиксированный набор переменных. Любая новая колонка в таблице ломает rows.Scan в рантайме, причём на проде, а не на сборке. Колонки перечисляются явно, это дешевле любой отладки.