database/sql и транзакции — бесплатный тест онлайн

Вопрос 1 из 30

На ревью разбирают тему «Пул соединений с базой». Каков наблюдаемый результат этого кода?

// Фрагмент для трассировки.
package main
import("database/sql";"time")
func tune(db *sql.DB){db.SetMaxOpenConns(20);db.SetMaxIdleConns(10);db.SetConnMaxLifetime(30*time.Minute)}
func main(){}

Один `*sql.DB` обслуживает параллельные запросы через несколько соединений по настройкам пула. Отложенный `Rollback` безопасно откатывает незавершённую транзакцию, а после успешного `Commit` обычно возвращает `sql.ErrTxDone`. Цикл может закончиться из-за ошибки сети, которую видно только в `rows.Err()`. Рост `db.WaitDuration` одновременно с исчерпанием пула указывает на очередь за соединениями, а не на нехватку CPU. Имя пользователя не меняет структуру запроса и не может добавить собственное условие SQL.

Вопрос 2 из 30

В разделе «Пул соединений с базой» показан конкретный случай. Какое изменение лучше всего укрепит контракт этого фрагмента?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("database/sql";"time")
func tune(db *sql.DB){db.SetMaxOpenConns(20);db.SetMaxIdleConns(10);db.SetConnMaxLifetime(30*time.Minute)}
func main(){}

Параметризовать все значения, а динамические имена столбцов выбирать только из закрытого белого списка. Начинать транзакцию с контекстом, проверять каждую ошибку, коммитить только после полного успеха. Создавать запрос с контекстом, проверять ошибку `Do`, статус и ограниченно читать тело, затем закрывать его. Ставить `defer rows.Close()` сразу после успешного `QueryContext` и проверять ошибку итерации. Открывать пул при старте, проверять `PingContext`, задавать MaxOpen/Idle и время жизни соединений по возможностям базы.

Вопрос 3 из 30

Команда проверяет решение по теме «Пул соединений с базой». Какое утверждение точнее всего описывает действующую гарантию?

// Определите правило Go, которое объясняет результат.
package main
import("database/sql";"time")
func tune(db *sql.DB){db.SetMaxOpenConns(20);db.SetMaxIdleConns(10);db.SetConnMaxLifetime(30*time.Minute)}
func main(){}

Значения передают параметрами драйвера, а не конкатенируют в SQL; синтаксис placeholder зависит от базы. Результат `Query` нужно закрыть и после цикла проверить `rows.Err`; `QueryRow` откладывает ошибку до `Scan`. `sql.DB` — безопасный конкурентный пул, а не одно физическое соединение; его создают надолго и настраивают лимиты. Комментарий экспортированного имени объясняет назначение, контракт, ошибки и конкурентную безопасность, а не повторяет сигнатуру. Все операции транзакции должны выполняться через `*sql.Tx`; смешивание с `db` выводит запрос за её границы.

Вопрос 4 из 30

Перед публикацией кода по теме «Пул соединений с базой» нужно уточнить контракт. Что может изменить вывод при небольшом изменении условий?

Увеличение числа горутин при одном глобальном мьютексе часто лишь увеличивает очередь. Параметр не заменяет идентификатор таблицы или направление сортировки в большинстве драйверов. Необработанная ошибка `Commit` может означать, что результат операции неизвестен вызывающему коду. Слишком маленький пул создаёт очередь, слишком большой способен перегрузить базу и исчерпать её лимит. Незакрытые строки удерживают соединение и постепенно исчерпывают пул.

Вопрос 5 из 30

В рабочем примере по теме «Пул соединений с базой» важно отделить гарантию от догадки. Как решение влияет на читаемость и надёжность?

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

Вопрос 6 из 30

В разделе «Параметры» показан конкретный случай. Что увидит вызывающий код после выполнения?

// Фрагмент для трассировки.
package main
import("context";"database/sql")
func find(ctx context.Context,db *sql.DB,name string)error{return db.QueryRowContext(ctx,"SELECT id FROM users WHERE name = ?",name).Scan(new(int))}
func main(){}

Один `*sql.DB` обслуживает параллельные запросы через несколько соединений по настройкам пула. Отложенный `Rollback` безопасно откатывает незавершённую транзакцию, а после успешного `Commit` обычно возвращает `sql.ErrTxDone`. Цикл может закончиться из-за ошибки сети, которую видно только в `rows.Err()`. Имя пользователя не меняет структуру запроса и не может добавить собственное условие SQL. Таблица проверяет `int64` и собственный `Age`, поэтому ловит ошибочное сужение ограничения.

Вопрос 7 из 30

Команда проверяет решение по теме «Параметры». Как подготовить этот код к реальному использованию?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("context";"database/sql")
func find(ctx context.Context,db *sql.DB,name string)error{return db.QueryRowContext(ctx,"SELECT id FROM users WHERE name = ?",name).Scan(new(int))}
func main(){}

Начинать транзакцию с контекстом, проверять каждую ошибку, коммитить только после полного успеха. Параметризовать все значения, а динамические имена столбцов выбирать только из закрытого белого списка. Открывать пул при старте, проверять `PingContext`, задавать MaxOpen/Idle и время жизни соединений по возможностям базы. Выбирать `ReadFull` для заголовков фиксированной длины и обычный цикл для произвольного потока. Ставить `defer rows.Close()` сразу после успешного `QueryContext` и проверять ошибку итерации.

Вопрос 8 из 30

Перед публикацией кода по теме «Параметры» нужно уточнить контракт. Какой контракт определяет результат показанного кода?

// Определите правило Go, которое объясняет результат.
package main
import("context";"database/sql")
func find(ctx context.Context,db *sql.DB,name string)error{return db.QueryRowContext(ctx,"SELECT id FROM users WHERE name = ?",name).Scan(new(int))}
func main(){}

`sql.DB` — безопасный конкурентный пул, а не одно физическое соединение; его создают надолго и настраивают лимиты. Вариативный параметр внутри функции имеет тип среза; существующий срез передают с `...`. Все операции транзакции должны выполняться через `*sql.Tx`; смешивание с `db` выводит запрос за её границы. Значения передают параметрами драйвера, а не конкатенируют в SQL; синтаксис placeholder зависит от базы. Результат `Query` нужно закрыть и после цикла проверить `rows.Err`; `QueryRow` откладывает ошибку до `Scan`.

Вопрос 9 из 30

В рабочем примере по теме «Параметры» важно отделить гарантию от догадки. Какое допущение здесь чаще всего оказывается ложным?

Параметр не заменяет идентификатор таблицы или направление сортировки в большинстве драйверов. Слишком маленький пул создаёт очередь, слишком большой способен перегрузить базу и исчерпать её лимит. Необработанная ошибка `Commit` может означать, что результат операции неизвестен вызывающему коду. Незакрытые строки удерживают соединение и постепенно исчерпывают пул. Если журналирование стоит внутри аутентификации, отвергнутые запросы могут не попасть в общий журнал.

Вопрос 10 из 30

Фрагмент относится к теме «Параметры». Какое замечание о цене решения будет точным?

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

Вопрос 11 из 30

Команда проверяет решение по теме «Транзакции». Что гарантированно произойдёт в показанной последовательности операций?

// Фрагмент для трассировки.
package main
import("context";"database/sql")
func run(ctx context.Context,db *sql.DB)error{tx,err:=db.BeginTx(ctx,nil);if err!=nil{return err};defer tx.Rollback();if _,err=tx.ExecContext(ctx,"UPDATE t SET n=n+1");err!=nil{return err};return tx.Commit()}
func main(){}

Отложенный `Rollback` безопасно откатывает незавершённую транзакцию, а после успешного `Commit` обычно возвращает `sql.ErrTxDone`. Цикл может закончиться из-за ошибки сети, которую видно только в `rows.Err()`. Один `*sql.DB` обслуживает параллельные запросы через несколько соединений по настройкам пула. Отложенная функция увеличивает именованный результат, поэтому `answer()` возвращает `2`, а не `1`. Имя пользователя не меняет структуру запроса и не может добавить собственное условие SQL.

Вопрос 12 из 30

Перед публикацией кода по теме «Транзакции» нужно уточнить контракт. Какой вариант исправления соответствует обычной практике Go?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("context";"database/sql")
func run(ctx context.Context,db *sql.DB)error{tx,err:=db.BeginTx(ctx,nil);if err!=nil{return err};defer tx.Rollback();if _,err=tx.ExecContext(ctx,"UPDATE t SET n=n+1");err!=nil{return err};return tx.Commit()}
func main(){}

Проверять заголовки, контекст, статус, паники и дополнительные интерфейсы ResponseWriter. Параметризовать все значения, а динамические имена столбцов выбирать только из закрытого белого списка. Ставить `defer rows.Close()` сразу после успешного `QueryContext` и проверять ошибку итерации. Открывать пул при старте, проверять `PingContext`, задавать MaxOpen/Idle и время жизни соединений по возможностям базы. Начинать транзакцию с контекстом, проверять каждую ошибку, коммитить только после полного успеха.

Вопрос 13 из 30

В рабочем примере по теме «Транзакции» важно отделить гарантию от догадки. Какой принцип языка объясняет результат полностью?

// Определите правило Go, которое объясняет результат.
package main
import("context";"database/sql")
func run(ctx context.Context,db *sql.DB)error{tx,err:=db.BeginTx(ctx,nil);if err!=nil{return err};defer tx.Rollback();if _,err=tx.ExecContext(ctx,"UPDATE t SET n=n+1");err!=nil{return err};return tx.Commit()}
func main(){}

Middleware выполняется конкурентно для запросов; изменяемые счётчики, кеши и ограничители должны быть безопасны. Все операции транзакции должны выполняться через `*sql.Tx`; смешивание с `db` выводит запрос за её границы. `sql.DB` — безопасный конкурентный пул, а не одно физическое соединение; его создают надолго и настраивают лимиты. Результат `Query` нужно закрыть и после цикла проверить `rows.Err`; `QueryRow` откладывает ошибку до `Scan`. Значения передают параметрами драйвера, а не конкатенируют в SQL; синтаксис placeholder зависит от базы.

Вопрос 14 из 30

Фрагмент относится к теме «Транзакции». Какой предел контракта важен для вызывающего кода?

Незаметное изменение конфигурации на лету может нарушить инварианты уже работающих компонентов. Слишком маленький пул создаёт очередь, слишком большой способен перегрузить базу и исчерпать её лимит. Незакрытые строки удерживают соединение и постепенно исчерпывают пул. Необработанная ошибка `Commit` может означать, что результат операции неизвестен вызывающему коду. Параметр не заменяет идентификатор таблицы или направление сортировки в большинстве драйверов.

Вопрос 15 из 30

На ревью разбирают тему «Транзакции». Как решение скажется на тестировании и дальнейших изменениях?

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

Вопрос 16 из 30

Перед публикацией кода по теме «Закрытие rows» нужно уточнить контракт. Какое наблюдение о работе кода будет верным?

// Фрагмент для трассировки.
package main
import("context";"database/sql")
func list(ctx context.Context,db *sql.DB)error{rows,err:=db.QueryContext(ctx,"SELECT id FROM t");if err!=nil{return err};defer rows.Close();for rows.Next(){var id int;if err:=rows.Scan(&id);err!=nil{return err}};return rows.Err()}
func main(){}

Один `*sql.DB` обслуживает параллельные запросы через несколько соединений по настройкам пула. GET можно повторить после временной сетевой ошибки, а POST без ключа идемпотентности может создать дубль. Цикл может закончиться из-за ошибки сети, которую видно только в `rows.Err()`. Отложенный `Rollback` безопасно откатывает незавершённую транзакцию, а после успешного `Commit` обычно возвращает `sql.ErrTxDone`. Имя пользователя не меняет структуру запроса и не может добавить собственное условие SQL.

Вопрос 17 из 30

В рабочем примере по теме «Закрытие rows» важно отделить гарантию от догадки. Какую правку разумнее внести до объединения изменений?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("context";"database/sql")
func list(ctx context.Context,db *sql.DB)error{rows,err:=db.QueryContext(ctx,"SELECT id FROM t");if err!=nil{return err};defer rows.Close();for rows.Next(){var id int;if err:=rows.Scan(&id);err!=nil{return err}};return rows.Err()}
func main(){}

Ставить `defer rows.Close()` сразу после успешного `QueryContext` и проверять ошибку итерации. Начинать транзакцию с контекстом, проверять каждую ошибку, коммитить только после полного успеха. Добавлять путь отмены через `context` или отдельный канал и гарантировать потребителя каждого результата. Параметризовать все значения, а динамические имена столбцов выбирать только из закрытого белого списка. Открывать пул при старте, проверять `PingContext`, задавать MaxOpen/Idle и время жизни соединений по возможностям базы.

Вопрос 18 из 30

Фрагмент относится к теме «Закрытие rows». Какое правило Go непосредственно объясняет поведение фрагмента?

// Определите правило Go, которое объясняет результат.
package main
import("context";"database/sql")
func list(ctx context.Context,db *sql.DB)error{rows,err:=db.QueryContext(ctx,"SELECT id FROM t");if err!=nil{return err};defer rows.Close();for rows.Next(){var id int;if err:=rows.Scan(&id);err!=nil{return err}};return rows.Err()}
func main(){}

Все операции транзакции должны выполняться через `*sql.Tx`; смешивание с `db` выводит запрос за её границы. `sql.DB` — безопасный конкурентный пул, а не одно физическое соединение; его создают надолго и настраивают лимиты. Результат `Query` нужно закрыть и после цикла проверить `rows.Err`; `QueryRow` откладывает ошибку до `Scan`. Значения передают параметрами драйвера, а не конкатенируют в SQL; синтаксис placeholder зависит от базы. Ошибка — значение, обычно возвращаемое отдельным результатом; `errors.New` подходит для постоянного сообщения без форматирования.

Вопрос 19 из 30

На ревью разбирают тему «Закрытие rows». Где заканчивается гарантия показанного приёма?

Не включать в ошибку секреты, токены, полные строки подключения и лишние персональные данные. Необработанная ошибка `Commit` может означать, что результат операции неизвестен вызывающему коду. Параметр не заменяет идентификатор таблицы или направление сортировки в большинстве драйверов. Незакрытые строки удерживают соединение и постепенно исчерпывают пул. Слишком маленький пул создаёт очередь, слишком большой способен перегрузить базу и исчерпать её лимит.

Вопрос 20 из 30

В разделе «Закрытие rows» показан конкретный случай. Когда этот приём помогает, а когда начинает мешать?

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

Вопрос 21 из 30

В рабочем примере по теме «Тестирование и наблюдаемость» важно отделить гарантию от догадки. Каков наблюдаемый результат этого кода?

// Фрагмент для трассировки.
package sample
// Псевдокод ожиданий: Begin -> Exec OK -> Exec error -> Rollback.
func main(){}

Тест ждёт событие по каналу и сообщает отдельную ошибку только если дедлайн действительно истёк. Тест считается успешным только если вызов действительно вызвал ожидаемую панику; отсутствие паники — отдельная ошибка теста. Тест с тысячей конкурентных увеличений ожидает точное итоговое значение под мьютексом. Тест ожидает `Rollback`, если второй запрос транзакции завершился ошибкой. Тест ошибки проверяет `errors.Is`, а не точное длинное сообщение с контекстом.

Вопрос 22 из 30

Фрагмент относится к теме «Тестирование и наблюдаемость». Какое изменение лучше всего укрепит контракт этого фрагмента?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
// Псевдокод ожиданий: Begin -> Exec OK -> Exec error -> Rollback.
func main(){}

Собирать статистику `db.Stats()`, время ожидания пула и длительность запросов без записи значений параметров-секретов. Добавлять тесты отмены и ограничения тела, а в журнале связывать запрос с идентификатором трассировки. Запускать тесты многократно, с `-race`, и собирать профили горутин при подозрении на утечку. Добавлять компиляционные проверки допустимых типов и обычные поведенческие тесты граничных значений. Записывать метод, хост, статус, длительность и категорию ошибки, не превращая URL с идентификаторами в метки высокой кардинальности.

Вопрос 23 из 30

На ревью разбирают тему «Тестирование и наблюдаемость». Какое утверждение точнее всего описывает действующую гарантию?

// Определите правило Go, которое объясняет результат.
package sample
// Псевдокод ожиданий: Begin -> Exec OK -> Exec error -> Rollback.
func main(){}

Обобщённый алгоритм тестируют представителями разных ветвей ограничения и именованными типами, а не только `int`. Потоковый код тестируют читателями, которые дробят данные, возвращают ошибки после байтов и выполняют короткие записи. Слой данных тестируют на ошибках начала, запроса, сканирования и коммита; отдельно нужен интеграционный тест реальной базы. Протокол канала тестируют на обычном пути, закрытии, отмене и отсутствии потребителя; зависание ограничивают таймаутом теста. Конвейер тестируют на пустом входе, ранней отмене, медленном потребителе и закрытии всех выходов; отдельно считают активные работники.

Вопрос 24 из 30

В разделе «Тестирование и наблюдаемость» показан конкретный случай. Что может изменить вывод при небольшом изменении условий?

Тест только успешного 200 не проверяет закрытие тела, медленные заголовки, разрыв соединения и повтор. Подмена SQL не воспроизводит блокировки, изоляцию и различия диалекта реальной базы. Зелёный health endpoint внутри процесса не доказывает доступность базы, очереди и внешнего маршрута. Тесты только внутри пакета могут случайно зависеть от деталей, недоступных реальному пользователю. Можно убрать отчёт гонки одной блокировкой, но сохранить логическую потерю обновления в другом месте.

Вопрос 25 из 30

Команда проверяет решение по теме «Тестирование и наблюдаемость». Как решение влияет на читаемость и надёжность?

Макет быстро проверяет ветвление ошибок, а контейнерная база нужна для транзакционной семантики и миграций. Модульный тест быстр, а отдельный `httptest.Server` нужен для маршрутизации, транспорта и завершения соединений. Виртуальное время делает тесты быстрыми, но требует дополнительной абстракции и проверки её соответствия реальным таймерам. Подменный транспорт даёт точный тест политики, а `httptest.Server` лучше проверяет настоящий HTTP-обмен. Синтетические источники дают детерминизм, но интеграционный тест всё равно нужен для реального файла или соединения.

Вопрос 26 из 30

Фрагмент относится к теме «Конкурентность и эксплуатация». Что увидит вызывающий код после выполнения?

// Фрагмент для трассировки.
package main
import "database/sql"
func stats(db *sql.DB)(int,int64){s:=db.Stats();return s.InUse,s.WaitCount}
func main(){}

Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Рост `db.WaitDuration` одновременно с исчерпанием пула указывает на очередь за соединениями, а не на нехватку CPU. Десятки горутин могут ждать свободное соединение, даже если процессор почти не занят. Идемпотентный `Close` через `sync.Once` безопасно останавливает одну фоновую горутину.

Вопрос 27 из 30

На ревью разбирают тему «Конкурентность и эксплуатация». Как подготовить этот код к реальному использованию?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "database/sql"
func stats(db *sql.DB)(int,int64){s:=db.Stats();return s.InUse,s.WaitCount}
func main(){}

Сочетать лимит параллелизма, отмену, предохранитель от серии ошибок и метрики насыщения пула. Иметь общий корневой контекст, идемпотентное закрытие, ограниченный льготный срок и принудительный финальный путь. Ограничивать кардинальность меток, контролировать очередь лимитера и не удерживать глобальную блокировку во время `next`. Ограничивать параллелизм, задавать контекст, отслеживать WaitCount/WaitDuration и избегать запросов N+1. Назначать уникальные порты через прослушивание `:0`, не менять глобальное окружение параллельно и закрывать серверы через Cleanup.

Вопрос 28 из 30

В разделе «Конкурентность и эксплуатация» показан конкретный случай. Какой контракт определяет результат показанного кода?

// Определите правило Go, которое объясняет результат.
package main
import "database/sql"
func stats(db *sql.DB)(int,int64){s:=db.Stats();return s.InUse,s.WaitCount}
func main(){}

Конфигурацию читают и валидируют до запуска рабочих горутин; секреты отделяют от безопасных параметров и не печатают целиком. Ограничение параллелизма и пула соединений защищает и клиент, и удалённый сервис от лавины запросов. Каждый запрос обычно обрабатывается конкурентно, поэтому общее состояние обработчика должно быть неизменяемым или синхронизированным. Параллельные запросы разделяют пул, а одна `Tx` обычно привязана к одному соединению и не является удобным общим объектом для независимых горутин. `Server.Shutdown` прекращает приём новых соединений и ждёт активные обработчики в пределах контекста.

Вопрос 29 из 30

Команда проверяет решение по теме «Конкурентность и эксплуатация». Какое допущение здесь чаще всего оказывается ложным?

Идентификатор пользователя, полный URL или текст ошибки в метке создаёт неограниченное число временных рядов. Нулевые серверные таймауты оставляют процесс уязвимым для очень медленных клиентов. Неограниченный fan-out к базе превращает краткий всплеск в очередь и каскад таймаутов. Увеличение числа горутин при одном глобальном мьютексе часто лишь увеличивает очередь. Повтор на каждом слое умножает попытки: три слоя по три попытки могут превратить один запрос в 27 обращений.

Вопрос 30 из 30

Перед публикацией кода по теме «Конкурентность и эксплуатация» нужно уточнить контракт. Какое замечание о цене решения будет точным?

Запас ёмкости переживает всплеск, но постоянная работа у предела лишает систему пространства для восстановления. Долгий срок сохраняет работу, но мешает быстрому откату; короткий увеличивает число оборванных запросов. Горячая перезагрузка уменьшает простой, но требует атомарного снимка и стратегии для параметров, которые нельзя менять безопасно. Большой пул уменьшает локальное ожидание до предела базы, после которого ухудшает работу всех клиентов. Быстрый откат уменьшает ущерб, но сохранение диагностических данных до изменения ускоряет поиск первопричины.