Транзакции в SQLite: просто, но со своими нюансами

SQLite - это встраиваемая база данных, и она немного отличается от привычных серверных СУБД (PostgreSQL, MySQL) в части работы с транзакциями. Но транзакции там есть, и работают по принципу ACID - атомарность, согласованность, изолированность и долговечность.

Разберёмся по полочкам:


🔹 Как начинается и заканчивается транзакция?

BEGIN TRANSACTION;
-- какие-то запросы
COMMIT;

Или, в случае ошибки:

ROLLBACK;

Можно использовать синонимы:
- BEGIN = BEGIN DEFERRED
- BEGIN IMMEDIATE
- BEGIN EXCLUSIVE

Они отличаются уровнем блокировок.


🔹 Типы транзакций

1. DEFERRED (по умолчанию)
🔒 Блокировки ставятся только при первом доступе к таблице (на чтение/запись).

2. IMMEDIATE
🔒 Сразу ставит блокировку на запись (write-lock). Полезно, если точно знаешь, что будешь писать — исключишь гонки.

3. EXCLUSIVE
🔒 Блокирует БД полностью. Даже другие чтения не пройдут.


🔹 Особенности SQLite

- Одна запись за раз: SQLite поддерживает одновременные чтения, но только одну запись одновременно. Остальные получат "database is locked".
- Авто-коммиты: если явно не начать транзакцию - SQLite будет делать коммит после каждого запроса.
- Журналирование: SQLite использует WAL (write-ahead log) или rollback journal - в зависимости от настроек. WAL - более производителен для параллельного чтения.


💡 Советы

- При пакетной вставке всегда оборачивай в транзакцию:

BEGIN;
INSERT INTO users VALUES (...);
INSERT INTO users VALUES (...);
...
COMMIT;

→ Это в разы быстрее, чем отдельные INSERT с автокоммитом.

- Если получаешь ошибку database is locked, проверь:
- Не оставил ли ты открытые транзакции
- Не работают ли несколько процессов с БД одновременно без координации


Сохрани, чтобы не потерять!

📲 Мы в MAX

#db

👉 @database_info

🐘 Открыт прием заявок на выступления для специалистов по PostgreSQL

Мероприятие: PG BootCamp Russia — официальное российское комьюнити-мероприятие PostgreSQL
Когда: весна 2026 г. (дата уточняется)
Где: г. Москва
Больше о мероприятиях PG BootCamp

В отличие от коммерческих конференций, предметом докладов выступает «ванильная» версия этой СУБД. Темы выступлений, связанные с коммерческими продуктами, не принимаются. Доклады (их обычно до 16 в два трека) делятся по темам разработки и эксплуатации. Формат предполагает камерную атмосферу, максимальную практическую пользу и содержательное профессиональное общение.

Открыт прием заявок на выступления:

🔹Исследование внутренней архитектуры PostgreSQL
🔹 Оптимизация производительности в высоконагруженных системах
🔹Анализ сложных задач и методов их решения
🔹 Инструменты и методологии для DBA
🔹 R&D-исследования, связанные с Postgres

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

🎙Подать заявку на выступление

🚨 Как понять, почему запрос тормозит?

Сегодня покажу простой, но действенный подход к диагностике медленных SQL-запросов. Когда к тебе приходит прод с жалобой "что-то всё виснет", важно не паниковать, а системно подойти к анализу.

Вот что я делаю первым делом:

1. Включаю EXPLAIN (ANALYZE)
Это ваш лучший друг. Не EXPLAIN, а именно ANALYZE, чтобы получить реальные значения времени, а не план на бумаге.

2. Смотрю на узлы с наибольшим временем
Часто виновник — Seq Scan по большой таблице или Nested Loop с миллионами итераций.

3. Ищу несработавшие индексы
Был ли Index Scan или Index Only Scan? Если нет — стоит проверить, почему не сработал индекс. Может, фильтр не селективный?

4. Проверяю фильтрацию и сортировку
ORDER BY может убить всё. Особенно если не по индексу.

5. Думаю про статистику
ANALYZE делали недавно? PostgreSQL может строить плохой план, если у него устаревшие данные.


🛠 Если ты часто отлаживаешь SQL — советую поставить pgMustard или использовать EXPLAIN DEPOT. Они визуализируют планы и сразу показывают узкие места.

📲 Мы в MAX

#db

👉 @database_info