HarborDB
Назад в блог
10 советов по производительности SQLite для приложений iOS и macOS
SQLite
Производительность
iOS
macOS

10 советов по производительности SQLite для приложений iOS и macOS

15 октября 2025 г.
Команда HarborDB

SQLite — это основа экосистемы Apple. Он является движком Core Data, поддерживает типичный прямой доступ к базе данных на iOS и macOS и служит форматом файлов приложений для бесчисленного количества приложений. Хотя SQLite известен как «нулевой конфигурации», переход от базовой реализации к высокопроизводительному движку, способному обрабатывать гигабайты данных и тысячи операций в секунду, требует глубокого понимания и целенаправленной настройки.

В этом подробном руководстве мы глубоко погрузимся во внутреннее устройство SQLite, исследуя расширенные настройки (PRAGMA), стратегии индексации и архитектурные шаблоны, специально адаптированные под ограничения и возможности устройств iOS и macOS.

1. Включите режим Write-Ahead Logging (WAL)

Самое эффективное изменение, которое вы можете внести в стандартную базу данных SQLite, — помочь ей обрабатывать параллелизм. По умолчанию SQLite использует «журнал отката» для обеспечения атомарности и устойчивости. Когда происходит транзакция записи, SQLite копирует исходные страницы в отдельный файл журнала перед записью в основной файл базы данных. Во время этого процесса база данных блокируется для чтения. Это означает, что читатели блокируют писателей, а писатели блокируют читателей.

Режим WAL (Write-Ahead Logging) инвертирует это. Изменения записываются в отдельный «WAL-файл» (часто с расширением -wal), а читатели продолжают читать из основного файла базы данных (и WAL-файла), не блокируясь писателем.

Почему WAL важен для приложений iOS

В iOS основной поток (Main Thread) часто должен читать данные для заполнения табличных представлений или коллекций. Если фоновый поток синхронизирует данные из API и записывает их в базу данных в режиме журнала отката, ваш основной поток заблокируется, вызывая подёргивания интерфейса (падение кадров). В режиме WAL ваш фоновый синхронизатор может свободно писать, пока основной поток читает последний зафиксированный снимок.

Как включить

Выполните эту команду PRAGMA. Она сохраняется, поэтому технически её нужно выполнить только один раз, но хорошей практикой является запуск при открытии соединения.

PRAGMA journal_mode = WAL;

Вывод: wal

Подробнее: Контрольные точки

В режиме WAL файл -wal растёт бесконечно до тех пор, пока операция «контрольной точки» не передаст страницы WAL обратно в основную базу данных .sqlite. По умолчанию SQLite создаёт автоматическую контрольную точку, когда WAL достигает 1000 страниц (примерно 4 МБ). Однако для интенсивных рабочих нагрузок записи вы можете настроить wal_autocheckpoint или запускать их вручную с помощью PRAGMA wal_checkpoint(PASSIVE|FULL|RESTART|TRUNCATE).

2. Используйте транзакции явно

Распространённое заблуждение, что отдельные SQL-запросы достаточно быстры. По умолчанию SQLite открывает транзакцию для каждого отдельного оператора, если она не запущена вручную. Это означает, что INSERT INTO table... фактически выполняет:

  1. Открыть транзакцию
  2. Создать файл журнала
  3. Записать данные
  4. Синхронизировать с диском (fsync)
  5. Закрыть транзакцию
  6. Удалить/аннулировать журнал

Этот fsync дорогостоящий, особенно на мобильных флеш-накопителях.

Пакетный подход

Группируйте ваши операции:

// ПЛОХО: 1000 fsync
for user in users {
    db.run("INSERT INTO users (name) VALUES (?)", user.name)
}

// ХОРОШО: 1 fsync
db.transaction {
    for user in users {
        db.run("INSERT INTO users (name) VALUES (?)", user.name)
    }
}

Тесты обычно показывают ускорение в 100–1000 раз для массовых вставок при использовании явных транзакций.

3. Освойте индексы: B-деревья, покрывающие и частичные индексы

Индексирование — это искусство. Слишком мало индексов — и вы сканируете всю таблицу (O(n)). Слишком много — и ваши операции создания/обновления замедляются (O(log n) на индекс).

Визуализация B-дерева

SQLite использует отдельные B-деревья для таблицы (на основе rowid) и для каждого индекса.

  • B-дерево таблицы хранит фактические данные в листовых узлах.
  • B-дерево индекса хранит индексированный ключ + rowid.

Покрывающие индексы

Чтобы запрашивать данные строго из индекса, не обращаясь к основной таблице (загружая дополнительные страницы), включите все извлекаемые столбцы в индекс.

Сценарий: У вас есть таблица users с id, name, email, last_login. Запрос: SELECT email FROM users WHERE name = 'Alice'

Стандартный индекс: CREATE INDEX idx_name ON users(name);

  1. Поиск idx_name по 'Alice' -> получение rowid.
  2. Поиск rowid в B-дереве таблицы -> загрузка страницы -> получение email.

Покрывающий индекс: CREATE INDEX idx_name_email ON users(name, email);

  1. Поиск idx_name_email по 'Alice'. email уже находится прямо здесь в листовом узле индекса. Результат возвращается мгновенно. Нулевых обращений к таблице.

Частичные индексы

Если вы запрашиваете только подмножество данных (например, «активных» пользователей), не индексируйте всю таблицу, чтобы сэкономить место.

CREATE INDEX idx_active_users_email 
ON users(email) 
WHERE status = 'active';

Этот индекс меньше, быстрее обновляется и быстрее запрашивается.

4. Подготовленные выражения — не обсуждаются

Анализ SQL требует больших затрат ЦПУ. SELECT * FROM users WHERE id = 1 и SELECT * FROM users WHERE id = 2 — это совершенно разные строки для парсера SQLite.

Подготовленное выражение компилирует план SQL-запроса в байт-код. Затем вы можете «привязать» параметры к нему и выполнить его несколько раз.

Пример на Swift (с использованием GRDB или SQLite.swift внутри)

Когда вы эффективно используете библиотеку, она кэширует эти выражения. Используйте заполнители (?) вместо интерполяции строк:

// ПЛОХО — компиляция происходит при каждой итерации цикла
let sql = "INSERT INTO users (name) VALUES ('\(name)')"
try db.execute(sql)

// ХОРОШО — скомпилировать один раз, выполнить много раз
let stmt = try db.prepare("INSERT INTO users (name) VALUES (?)")
for name in names {
    try stmt.run(name)
}

Это значительно снижает нагрузку на ЦПУ, что также экономит заряд батареи на мобильных устройствах.

5. Оптимизируйте настройки PRAGMA

Настройки по умолчанию в SQLite консервативны (ориентированы на оборудование 2005 года). Современные iPhone имеют хранилище класса NVMe и гигабайты ОЗУ.

temp_store

По умолчанию временные таблицы и индексы хранятся на диске. Переместите их в ОЗУ:

PRAGMA temp_store = MEMORY;

mmap_size

Ввод-вывод с отображением в память может быть быстрее стандартных системных вызовов чтения/записи, поскольку он избегает копирования данных между пространством ядра и пользовательским пространством.

PRAGMA mmap_size = 268435456; -- 256 МБ

Примечание: Будьте осторожны с mmap, если у вас есть предупреждения о высоком давлении памяти в iOS, но для умеренных наборов данных это огромный ускоритель чтения.

synchronous

В режиме WAL по умолчанию используется NORMAL. Это достаточно безопасно для большинства приложений (вы можете потерять самую последнюю транзакцию при потере питания, но не повредить базу данных). Избегайте FULL или EXTRA, если вы не пишете банковское программное обеспечение, где улучшенная устойчивость стоит снижения скорости записи примерно на 20%.

PRAGMA synchronous = NORMAL;

6. Понимание планировщика запросов (EXPLAIN QUERY PLAN)

Никогда не угадывайте, почему запрос медленный. SQLite расскажет вам. Добавьте к вашему запросу префикс EXPLAIN QUERY PLAN.

EXPLAIN QUERY PLAN SELECT * FROM orders WHERE user_id = 5 AND created_at > 1000;

Анализ вывода:

  • SCAN TABLE: Плохо. Читает каждую строку.
  • SEARCH TABLE USING INDEX: Хорошо. Использует поиск по B-дереву.
  • USE TEMP B-TREE: Предупреждение. Пришлось построить временный индекс (вероятно, для сортировки).

HarborDB (наш продукт) уделяет большое внимание визуализации этих планов, но вы можете прочитать сырой вывод в любой CLI.

7. Обрабатывайте SQLITE_BUSY корректно

Даже в режиме WAL могут возникать разделяемые блокировки. Если писатель завершает фиксацию, читатель может быть ненадолго заблокирован. По умолчанию SQLite немедленно возвращает SQLITE_BUSY. В iOS вы должны установить тайм-аут, чтобы SQLite повторил попытку внутренне перед сдачей.

PRAGMA busy_timeout = 3000; -- 3000 миллисекунд

Эта простая настройка предотвращает 99% ошибок «Database is locked» в параллельных приложениях.

8. Денормализация для скорости на мобильных устройствах

Строгая нормализация (3NF) хороша для эффективности хранения и согласованности, но мобильные экраны часто нуждаются в «соединённых» данных мгновенно. Соединения дороги (O(M * log N)).

Если у вас есть список Posts, который показывает AuthorName и CommentCount, рассмотрите возможность хранения AuthorName и CommentCount непосредственно в таблице Posts. Да, вам придётся обновлять таблицу Posts, когда автор меняет своё имя или добавляется комментарий (триггеры могут автоматизировать это!), но ваша СКОРОСТЬ ЧТЕНИЯ (которая происходит в 100 раз чаще, чем запись) становится O(1) на строку вместо выполнения массивных JOIN при прокрутке.

9. Эффективная пагинация (Избегайте OFFSET)

Стандартная веб-пагинация LIMIT 20 OFFSET 100 токсична в SQLite для больших наборов данных. Чтобы добраться до OFFSET 10000, SQLite должен вычислить первые 10 000 строк и выбросить их. Это становится линейно медленнее, чем глубже вы листаете.

Метод Keyset (Seek): Запомните последнее видимое значение. Запрос: SELECT * FROM items WHERE created_at < ? ORDER BY created_at DESC LIMIT 20

Это использует индекс для мгновенного перехода в правильное место. Это O(log N) независимо от глубины страницы.

10. Очистка и обслуживание

Базы данных фрагментируются. Когда вы удаляете данные, SQLite помечает страницы как «свободные», но не уменьшает размер файла.

  • VACUUM: Перестраивает файл базы данных с нуля. Идеально компактный. Медленный. Эксклюзивная блокировка.
  • PRAGMA auto_vacuum = INCREMENTAL: Позволяет периодически восстанавливать пространство без блокировки всего мира.

Для приложений iOS мы рекомендуем:

  1. Используйте auto_vacuum = NONE (по умолчанию) для производительности.
  2. Запускайте полный VACUUM только во время основных миграций или редких окон обслуживания (например, обновление приложения), так как это требует места на диске (в 2 раза больше размера БД) и времени.

Заключение

Оптимизация производительности SQLite/PostgreSQL — это путь понимания оборудования, файловой системы и структур B-деревьев. Включив режим WAL, используя правильные индексы и понимая планировщик запросов, практически любую «медленную» функциональность в вашем приложении iOS/macOS можно сделать мгновенной.

Для разработчиков, которые хотят видеть эти метрики производительности в реальном времени и визуализировать свои планы запросов, нативные инструменты, такие как HarborDB, предоставляют значительное преимущество перед догадками в командной строке.