Утверждения PRAGMA

Утверждение PRAGMA — это расширение SQL, специфичное для SQLite, используемое для изменения работы библиотеки SQLite или для запроса к библиотеке SQLite внутренних (не табличных) данных. Утверждение PRAGMA выполняется с помощью того же интерфейса, что и другие команды SQLite (например, SELECT, INSERT), но отличается в следующих важных аспектах:

• Команда pragma специфична для SQLite и несовместима ни с одним другим движком SQL баз данных.
• Конкретные утверждения pragma могут быть удалены, а другие добавлены в будущих версиях SQLite. Гарантии обратной совместимости нет.
• Если выдано неизвестное утверждение pragma, сообщения об ошибках не генерируются. Неизвестные pragmas просто игнорируются. Это означает, что если в утверждении pragma допущена опечатка, библиотека не информирует пользователя об этом.
• Некоторые pragmas вступают в силу на стадии компиляции SQL, а не на стадии выполнения. Это означает, что при использовании API языка C sqlite3_prepare(), sqlite3_step(), sqlite3_finalize() (или аналогичного в интерфейсе обертки), pragma может выполняться во время вызова sqlite3_prepare(), а не во время вызова sqlite3_step(), как это делают обычные операторы SQL. Или же pragma может выполняться во время sqlite3_step() также, как и обычные операторы SQL. Выполняется ли pragma во время sqlite3_prepare() или sqlite3_step(), зависит от pragma и от конкретной версии SQLite.
• Префиксы EXPLAIN и EXPLAIN QUERY PLAN для операторов SQL влияют только на поведение оператора во время sqlite3_step(). Это означает, что утверждения PRAGMA, которые вступают в силу во время sqlite3_prepare(), будут вести себя одинаково независимо от того, предваряются ли они префиксом "EXPLAIN".

API языка C для SQLite предоставляет SQLITE_FCNTL_PRAGMA управление файлами, которое предоставляет реализациям VFS возможность добавления новых утверждений PRAGMA или переопределения значения встроенных утверждений PRAGMA.

Синтаксис команды PRAGMA

pragma-stmt: скрыть

Утверждение pragma может принимать ноль или один аргумент. Аргумент может быть заключён в скобки или отделён от имени pragma знаком равенства. Оба синтаксиса дают одинаковые результаты. Во многих утверждениях pragma аргумент является булевым. Булевое значение может быть одним из следующих:

Ключевые слова в качестве аргументов могут необязательно быть заключены в кавычки. (Пример: 'yes' [FALSE].) Некоторые pragmas принимают строковый литерал в качестве аргумента. Когда pragma принимает ключевой аргумент, он, как правило, также принимает числовой эквивалент. Например, "0" и "нет" означают одно и то же, как и "1" и "да". При запросе значения настройки многие pragmas возвращают число, а не ключевое слово.

Утверждение pragma может иметь необязательное имя схемы перед именем pragma. Имя схемы — это имя присоединённой базы данных ATTACH или «main» или «temp» для основных и временных баз данных. Если необязательное имя схемы опущено, предполагается «main». В некоторых pragmas имя схемы не имеет смысла и просто игнорируется. В документации ниже, pragmas, для которых имя схемы имеет смысл, показаны с префиксом «схема.».

Функции PRAGMA

Доступ к PRAGMA, возвращающим результаты и не имеющим побочных эффектов, возможен из обычных операторов SELECT в качестве таблично-значимых функций. Для каждого участвующего PRAGMA соответствующая таблично-значимая функция имеет то же имя, что и PRAGMA, с 7-символьным префиксом "pragma_". Аргумент и схема PRAGMA, если таковые имеются, передаются в качестве аргументов таблично-значимой функции, при этом схема является необязательным последним аргументом.

Например, информацию о столбцах в индексе можно прочитать, используя pragma index_info следующим образом:

PRAGMA index_info('idx52');

Или ту же информацию можно прочитать так:

SELECT * FROM pragma_index_info('idx52');

Преимущества использования формата таблично-значимых функций заключаются в том, что запрос может возвращать только подмножество столбцов PRAGMA, может включать условие WHERE, может использовать агрегатные функции, а таблично-значимая функция может быть одним из нескольких источников данных в соединении. Например, чтобы получить список всех индексированных столбцов в схеме, можно выполнить запрос:

SELECT DISTINCT m.name || '.' || ii.name AS 'indexed-columns'
  FROM sqlite_schema AS m,
       pragma_index_list(m.name) AS il,
       pragma_index_info(il.name) AS ii
 WHERE m.type='table'
 ORDER BY 1;

Дополнительные замечания:

• Таблично-значимые функции существуют только для встроенных PRAGMA, а не для PRAGMA, определенных с помощью системного вызова SQLITE_FCNTL_PRAGMA.

• Таблично-значимые функции существуют только для PRAGMA, возвращающих результаты и не имеющих побочных эффектов.

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

  ATTACH ':memory:' AS 'information_schema';
  

  Затем создав VIEW в этой схеме, которые реализуют таблицы официальной информационной схемы с использованием таблично-значимых функций PRAGMA.

• Таблично-значимые функции для PRAGMA были добавлены в SQLite версии 3.16.0 (2017-01-02). Предыдущие версии SQLite не могут использовать эту функцию.

Список PRAGMA

Примечания:

1. PRAGMA, имена которых перечеркнуты, устарели. Не использовать. Они существуют для обеспечения обратной совместимости.
2. Эти PRAGMA доступны только в сборках, использующих нестандартные параметры компиляции.
3. Эти PRAGMA используются для тестирования SQLite и не рекомендуются для использования в прикладных программах.

PRAGMA analysis_limit;
PRAGMA analysis_limit = N;

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

Этот pragma может помочь команде ANALYZE работать быстрее на больших базах данных. Результаты анализа не так хороши, когда проверяется только часть каждого индекса, но обычно они достаточно хорошие. Установка N в 100 или 1000 позволяет команде ANALYZE работать быстро, даже на огромных файлах базы данных.

Этот pragma был добавлен в SQLite версии 3.32.0 (2020-05-22). Текущая реализация использует только нижние 31 бит значения N — старшие биты игнорируются. Будущие версии SQLite могут начать использовать старшие биты.

Начиная с версии SQLite 3.46.0 (2024-05-23), рекомендуемый способ запуска ANALYZE — с помощью команды PRAGMA optimize. Команда PRAGMA optimize автоматически установит разумный временный предел анализа, гарантируя, что команда PRAGMA optimize завершится быстро даже на огромных базах данных. Приложениям, использующим PRAGMA optimize вместо непосредственного запуска ANALYZE, устанавливать предел анализа не нужно.

PRAGMA schema.application_id;
PRAGMA schema.application_id = integer ;

PRAGMA application_id используется для запроса или установки 32-битного целого числа "Идентификатор приложения" в формате big-endian, расположенного в смещении 68 в заголовке базы данных. Приложения, использующие SQLite в качестве своего формата файла приложения, должны установить целое число Идентификатора приложения на уникальное значение, чтобы утилиты, такие как file(1), могли определить специфический тип файла, а не просто сообщить "База данных SQLite3". Список назначенных идентификаторов приложений можно посмотреть в файле magic.txt в репозитории исходного кода SQLite.

См. также pragma user_version.

PRAGMA schema.auto_vacuum;
PRAGMA schema.auto_vacuum = 0 | NONE | 1 | FULL | 2 | INCREMENTAL;

Запрос или установка состояния автоматического вакуума в базе данных.

Значение по умолчанию для auto-vacuum — 0 или "none", если не используется опция компиляции SQLITE_DEFAULT_AUTOVACUUM. Настройка "none" означает отключение автоматического вакуума. При отключенном автоматическом вакууме и удалении данных из базы данных, размер файла базы данных остается прежним. Неиспользуемые страницы файла базы данных добавляются в "freelist" и повторно используются для последующих вставок. Таким образом, пространство файла базы данных не теряется. Однако, размер файла базы данных не уменьшается. В этом режиме можно использовать команду VACUUM для перестроения всего файла базы данных и, таким образом, освободить неиспользуемое дисковое пространство.

Когда режим автоматического вакуума равен 1 или "full", страницы freelist перемещаются в конец файла базы данных, а файл базы данных усекается для удаления страниц freelist при каждом подтверждении транзакции. Обратите внимание, однако, что автоматический вакуум только усекает страницы freelist из файла. Автоматический вакуум не дефрагментирует базу данных и не упаковывает отдельные страницы базы данных так, как это делает команда VACUUM. На самом деле, из-за перемещения страниц внутри файла автоматический вакуум может фактически ухудшить фрагментацию.

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

Если значение auto-vacuum равно 2 или «incremental», то дополнительная информация, необходимая для автоматической очистки кеша, хранится в файле базы данных, но автоматическая очистка кеша не происходит автоматически при каждом подтверждении, как это происходит при auto_vacuum=full. В режиме инкрементального режима необходимо вызвать отдельный incremental_vacuum pragma, чтобы запустить автоматическую очистку кеша.

Подключение к базе данных может быть изменено между режимами полной и инкрементальной автоматической очисткой кеша в любое время. Однако переход от «none» к «full» или «incremental» возможен только в случае новой базы данных (если таблицы еще не созданы) или путем выполнения команды VACUUM. Чтобы изменить режимы автоматической очистки кеша, сначала используйте pragma auto_vacuum для установки нового желаемого режима, а затем выполните команду VACUUM для переорганизации всего файла базы данных. Чтобы перейти от «full» или «incremental» обратно к «none», всегда необходимо выполнить VACUUM, даже на пустой базе данных.

При вызове pragma auto_vacuum без аргументов возвращается текущий режим auto_vacuum.

PRAGMA automatic_index;
PRAGMA automatic_index = boolean;

Запрос, установка или отключение возможности автоматического индексирования.

Автоматическое индексирование включено по умолчанию начиная с версии 3.7.17 (2013-05-20), но это может измениться в будущих выпусках SQLite.

PRAGMA busy_timeout;
PRAGMA busy_timeout = milliseconds;

Запрос или изменение параметра busy timeout. Этот pragma является альтернативой интерфейсу языка C sqlite3_busy_timeout(), который предоставляется как pragma для использования с языковыми связями, не предоставляющими прямой доступ к sqlite3_busy_timeout().

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

PRAGMA schema.cache_size;
PRAGMA schema.cache_size = pages;
PRAGMA schema.cache_size = -kibibytes;

Запрос или изменение рекомендуемого максимального количества страниц диска базы данных, которые SQLite будет держать в памяти одновременно для каждого открытого файла базы данных. Будет ли это предложение принято, зависит от Приложение определяет кэш страниц. Кэш страниц по умолчанию, встроенный в SQLite, принимает запрос, однако альтернативные реализации кэша страниц, определённые приложением, могут интерпретировать рекомендуемый размер кэша по-разному или вообще игнорировать его. Рекомендуемый размер кэша по умолчанию составляет -2000, что означает, что размер кэша ограничен 2048000 байтами памяти. Рекомендуемый размер кэша по умолчанию может быть изменён с помощью параметров компиляции SQLITE_DEFAULT_CACHE_SIZE. Для временной базы данных (TEMP) рекомендуемый размер кэша по умолчанию равен 0 страниц.

Если аргумент N положителен, то рекомендуемый размер кэша устанавливается в N. Если аргумент N отрицателен, то количество страниц кэша корректируется таким образом, чтобы использовать приблизительно abs(N*1024) байтов памяти на основе текущего размера страницы. SQLite запоминает количество страниц в кэше страниц, а не количество используемой памяти. Поэтому, если вы установите размер кэша с помощью отрицательного числа, а затем измените размер страницы (с помощью команды PRAGMA page_size), то максимальное количество памяти кэша увеличится или уменьшится пропорционально изменению размера страницы.

Примечание обратной совместимости: Поведение cache_size с отрицательным N отличалось до версии 3.7.10 (2012-01-16). В более ранних версиях количество страниц в кэше устанавливалось равным абсолютному значению N.

При изменении размера кэша с помощью pragm cache_size, изменение сохраняется только для текущей сессии. Размер кэша возвращается к значению по умолчанию при закрытии и повторном открытии базы данных.

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

PRAGMA cache_spill;
PRAGMA cache_spill=boolean;
PRAGMA schema.cache_spill=N;

Pragma cache_spill включает или отключает возможность пейджера выгружать грязные страницы кэша в файл базы данных в середине транзакции. Cache_spill включён по умолчанию, и большинство приложений должны оставить его в таком виде, так как выгрузка кэша обычно выгодна. Однако выгрузка кэша имеет побочный эффект — получение EXCLUSIVE lock на файле базы данных. Следовательно, некоторые приложения с большими долговременными транзакциями могут захотеть отключить выгрузку кэша, чтобы предотвратить получение приложением эксклюзивной блокировки на базе данных до момента, когда транзакция COMMIT.

Форма «PRAGMA cache_spill=N» этого pragm устанавливает минимальный порог размера кэша, необходимый для выгрузки. Количество страниц в кэше должно превышать как порог выгрузки cache_spill, так и максимальный размер кэша, установленный оператором PRAGMA cache_size, для того, чтобы произошла выгрузка.

Форма «PRAGMA cache_spill=boolean» этого pragm применяется ко всем базам данных, подключенным к подключению к базе данных. Но форма «PRAGMA cache_spill=N» этого оператора применяется только к схеме «главная» или к любой другой схеме, указанной в операторе.

PRAGMA case_sensitive_like = boolean;

Поведение оператора LIKE по умолчанию заключается в игнорировании регистра для ASCII-символов. Таким образом, по умолчанию 'a' LIKE 'A' — истинно. Pragma case_sensitive_like устанавливает новую функцию LIKE, которая чувствительна или нечувствительна к регистру в зависимости от значения pragm case_sensitive_like. Когда case_sensitive_like выключен, используется стандартное поведение LIKE. Когда case_sensitive_like включен, регистр становится значимым. Например, 'a' LIKE 'A' — ложно, но 'a' LIKE 'a' всё ещё истинно.

Этот pragma использует sqlite3_create_function() для перегрузки функций LIKE и GLOB, что может переопределить предыдущие реализации LIKE и GLOB, зарегистрированные приложением. Этот pragma изменяет только поведение оператора SQL LIKE. Он не изменяет поведение интерфейса языка C sqlite3_strlike(), которое всегда нечувствительно к регистру.

ПРЕДУПРЕЖДЕНИЕ: Если база данных использует оператор LIKE где-либо в схеме, например, в ограничении CHECK или в индексе выражения или в предложении WHERE частичного индекса, то изменение определения оператора LIKE с помощью этого pragm может привести к тому, что база данных будет выглядеть повреждённой. PRAGMA integrity_check сообщит об ошибках. База данных на самом деле не повреждена, так как изменение поведения LIKE обратно к тому, каким оно было при определении схемы и заполнении базы данных, устранит проблему. Если использование LIKE происходит только в индексах, проблему можно устранить, выполнив REINDEX. Тем не менее, использование pragma case_sensitive_like не рекомендуется.

Этот pragma устарел и существует только для обратной совместимости. Новым приложениям следует избегать использования этого pragm. Старые приложения должны прекратить его использование при первой же возможности. Этот pragma может быть исключён из сборки, когда SQLite скомпилирован с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA cell_size_check
PRAGMA cell_size_check = boolean;

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

PRAGMA checkpoint_fullfsync
PRAGMA checkpoint_fullfsync = boolean;

Запрос или изменение флага fullfsync для операций checkpoint. Если этот флаг установлен, то во время операций checkpoint на системах, поддерживающих F_FULLFSYNC, используется метод синхронизации F_FULLFSYNC. Значение флага checkpoint_fullfsync по умолчанию — выключено. Только Mac OS-X поддерживает F_FULLFSYNC.

Если флаг fullfsync установлен, то метод синхронизации F_FULLFSYNC используется для всех операций синхронизации, а значение checkpoint_fullfsync не имеет значения.

PRAGMA collation_list;

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

PRAGMA compile_options;

Этот pragma возвращает имена параметров компиляции, используемых при построении SQLite, по одному параметру на строку. Префикс «SQLITE_» опускается из возвращённых имён параметров. См. также интерфейс C/C++ sqlite3_compileoption_get() и SQL-функции sqlite_compileoption_get().

PRAGMA count_changes;
PRAGMA count_changes = boolean;

Запрос или изменение флага count-changes. Обычно, когда флаг count-changes не установлен, операторы INSERT, UPDATE и DELETE не возвращают данных. Когда count-changes установлен, каждый из этих команд возвращает одну строку данных, содержащую одно целочисленное значение — количество строк, добавленных, изменённых или удалённых командой. Возвращаемое количество изменений не включает любые вставки, изменения или удаления, выполняемые триггерами, любые изменения, автоматически выполняемые действиями внешних ключей, или обновления, вызванные upsert.

Другой способ получить количество изменений строк — использовать интерфейсы sqlite3_changes() или sqlite3_total_changes(). Однако есть небольшое отличие. Когда INSERT, UPDATE или DELETE выполняются над представлением с использованием триггера INSTEAD OF, команда count_changes возвращает количество строк в представлении, которое сработало триггер, в то время как sqlite3_changes() и sqlite3_total_changes() этого не делают.

Эта команда устарела и существует только для обратной совместимости. Новым приложениям следует избегать использования этой команды. Старые приложения должны прекратить использование этой команды в ближайшее время. Эта команда может быть исключена из сборки, если SQLite скомпилирован с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA data_store_directory;
PRAGMA data_store_directory = 'имя_каталога';

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

Изменение параметра data_store_directory не является потокобезопасным. Никогда не изменяйте параметр data_store_directory, если другой поток в приложении в это же время выполняет какой-либо интерфейс SQLite. Это приводит к неопределённому поведению. Изменение параметра data_store_directory записывает данные в глобальную переменную sqlite3_data_directory, а эта глобальная переменная не защищена мьютексом.

Эта функция предоставляется для WinRT, в котором нет механизма ОС для чтения или изменения текущей рабочей директории. Использование этой команды в других контекстах не рекомендуется и может быть запрещено в будущих выпусках.

Эта команда устарела и существует только для обратной совместимости. Новым приложениям следует избегать использования этой команды. Старые приложения должны прекратить использование этой команды в ближайшее время. Эта команда может быть исключена из сборки, если SQLite скомпилирован с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA schema.data_version;

Команда "PRAGMA data_version" указывает, что файл базы данных был изменён. Интерактивные программы, хранящие содержимое базы данных в памяти или отображающие содержимое базы данных на экране, могут использовать команду PRAGMA data_version, чтобы определить, нужно ли им очистить и перезагрузить память или обновить отображение на экране.

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

Значение "PRAGMA data_version" — локальное свойство каждого соединения с базой данных, поэтому значения, возвращённые двумя одновременными вызовами "PRAGMA data_version" в разных соединениях с базой данных, часто различны, даже если основная база данных идентична. Имеет смысл сравнивать значения "PRAGMA data_version", возвращённые одним и тем же соединением с базой данных в разные моменты времени.

PRAGMA database_list;

Эта команда работает как запрос, возвращающий одну строку для каждой базы данных, присоединённой к текущему соединению с базой данных. Второй столбец — "main" для основного файла базы данных, "temp" для файла базы данных, используемого для хранения временных объектов, или имя присоединённой базы данных для других файлов баз данных. Третий столбец — имя самого файла базы данных или пустая строка, если база данных не связана с файлом.

Эта команда запроса или устанавливает рекомендуемое максимальное количество страниц кэша диска, которое будет выделено на каждый открытый файл базы данных. Разница между этой командой и cache_size заключается в том, что значение, установленное здесь, сохраняется между соединениями с базой данных. Значение размера кэша по умолчанию хранится в 4-байтовом целочисленном значении big-endian, расположенном по смещению 48 в заголовке файла базы данных.

Эта команда устарела и существует только для обратной совместимости. Новым приложениям следует избегать использования этой команды. Старые приложения должны прекратить использование этой команды в ближайшее время. Эта команда может быть исключена из сборки, если SQLite скомпилирован с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA defer_foreign_keys
PRAGMA defer_foreign_keys = логическое_значение;

При включенном параметре defer_foreign_keys проверка всех ограничений внешнего ключа откладывается до момента коммита самого внешнего транзакции. Команда defer_foreign_keys по умолчанию выключена, поэтому ограничения внешнего ключа откладываются только если они созданы как "DEFERRABLE INITIALLY DEFERRED". Команда defer_foreign_keys автоматически выключается при каждом COMMIT или ROLLBACK. Следовательно, команда defer_foreign_keys должна быть отдельно включена для каждой транзакции. Эта команда имеет смысл только если ограничения внешнего ключа включены.

Интерфейс C-языка sqlite3_db_status(db,SQLITE_DBSTATUS_DEFERRED_FKS,...) может использоваться во время транзакции для определения наличия отложенных и неразрешённых ограничений внешнего ключа.

PRAGMA empty_result_callbacks;
PRAGMA empty_result_callbacks = логическое_значение;

Запрос или изменение флага empty-result-callbacks.

Флаг empty-result-callbacks влияет только на API sqlite3_exec(). Обычно, когда флаг empty-result-callbacks очищен, функция обратного вызова, переданная в sqlite3_exec(), не вызывается для команд, которые возвращают нулевые строки данных. Когда empty-result-callbacks установлен в этом случае, функция обратного вызова вызывается ровно один раз, со значением третьего параметра 0 (NULL). Это позволяет программам, использующим API sqlite3_exec(), получать имена столбцов даже когда запрос не возвращает данных.

Эта команда устарела и существует только для обратной совместимости. Новым приложениям следует избегать использования этой команды. Старые приложения должны прекратить использование этой команды в ближайшее время. Эта команда может быть исключена из сборки, если SQLite скомпилирован с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA encoding;
PRAGMA encoding = 'UTF-8';
PRAGMA encoding = 'UTF-16';
PRAGMA encoding = 'UTF-16le';
PRAGMA encoding = 'UTF-16be';

В первом варианте, если основная база данных уже создана, эта команда возвращает используемое кодирование текста основной базы данных, одно из 'UTF-8', 'UTF-16le' (кодирование UTF-16 с младшим порядком байтов) или 'UTF-16be' (кодирование UTF-16 со старшим порядком байтов). Если основная база данных ещё не создана, возвращаемое значение — кодирование текста, которое будет использоваться для создания основной базы данных, если она будет создана в этом сеансе.

Второй и последующие варианты этой команды устанавливают кодирование, с которым будет создана основная база данных, если она создаётся в этом сеансе. Строка 'UTF-16' интерпретируется как "кодирование UTF-16 с использованием родного порядка байтов машины". Невозможно изменить кодирование текста базы данных после её создания, и любая попытка сделать это будет проигнорирована.

Если кодирование не задано командой PRAGMA, то по умолчанию используется кодирование, определенное интерфейсом API, используемым для открытия соединения.

После установки кодирования базы данных его нельзя изменить.

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

PRAGMA schema.foreign_key_check;
PRAGMA schema.foreign_key_check(имя_таблицы);

Команда foreign_key_check проверяет базу данных или таблицу с именем "имя_таблицы" на нарушение ограничений внешнего ключа. Команда foreign_key_check возвращает одну строку вывода для каждого нарушения ограничения внешнего ключа. В каждой строке результата четыре столбца. Первый столбец — имя таблицы, содержащей предложение REFERENCES. Второй столбец — rowid строки, содержащей неверное предложение REFERENCES, или NULL, если таблица дочерняя — таблица WITHOUT ROWID. Третий столбец — имя таблицы, к которой осуществляется ссылка. Четвёртый столбец — индекс конкретного нарушения ограничения внешнего ключа. Четвёртый столбец в выводе команды foreign_key_check — то же целое число, что и первый столбец в выводе команды foreign_key_list. Если указано имя "имя_таблицы", проверяются только те ограничения внешнего ключа, которые созданы с помощью предложений REFERENCES в операторе CREATE TABLE для имя_таблицы.

PRAGMA foreign_key_list(имя_таблицы);

Эта команда возвращает одну строку для каждого ограничения внешнего ключа, созданного с помощью предложения REFERENCES в операторе CREATE TABLE таблицы "имя_таблицы".

PRAGMA foreign_keys;
PRAGMA foreign_keys = логическое_значение;

Запрос, установка или отключение проверки ограничений внешнего ключа.

Эта команда является пустой операцией внутри транзакции; проверка ограничений внешнего ключа может быть включена или выключена только при отсутствии ожидающего BEGIN или SAVEPOINT.

Изменение параметра foreign_keys влияет на выполнение всех подготовленных с помощью соединения с базой данных запросов, включая запросы, подготовленные до изменения параметра. Любые существующие запросы, подготовленные с помощью устаревшего интерфейса sqlite3_prepare(), могут завершиться ошибкой SQLITE_SCHEMA после изменения параметра foreign_keys.

Начиная с версии SQLite 3.6.19, значение по умолчанию для проверки ограничений внешнего ключа — ВЫКЛ. Однако это может измениться в будущих версиях SQLite. Значение по умолчанию для проверки ограничений внешнего ключа может быть указано на этапе компиляции с помощью препроцессорной макрокоманды SQLITE_DEFAULT_FOREIGN_KEYS. Для минимизации будущих проблем приложения должны устанавливать флаг проверки ограничений внешнего ключа в соответствии с требованиями приложения и не полагаться на значение по умолчанию.

PRAGMA schema.freelist_count;

Возвращает количество неиспользуемых страниц в файле базы данных.

PRAGMA full_column_names;
PRAGMA full_column_names = boolean;

Запрос или изменение флага full_column_names. Этот флаг вместе с флагом short_column_names определяет способ, которым SQLite присваивает имена столбцам результатов операторов SELECT. Имена столбцов результатов формируются по следующим правилам:

1. Если есть предложение AS, то имя столбца — это правая часть предложения AS.

2. Если результат — это общее выражение, а не просто имя столбца таблицы-источника, то имя результата — это копия текста выражения.

3. Если прагма short_column_names установлена в ВКЛ, то имя результата — это имя столбца таблицы-источника без префикса имени таблицы-источника: COLUMN.

4. Если обе прагмы short_column_names и full_column_names установлены в ВЫКЛ, то применяется правило (2).

5. Имя столбца результата — это комбинация имени таблицы-источника и имени столбца-источника: TABLE.COLUMN

Эта прагма устарела и существует только для обеспечения обратной совместимости. Новым приложениям следует избегать использования этой прагмы. Старые приложения должны прекратить использование этой прагмы в ближайшее время. Эта прагма может быть опущена при компиляции SQLite с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA fullfsync
PRAGMA fullfsync = boolean;

Запрос или изменение флага fullfsync. Этот флаг определяет, используется ли метод синхронизации F_FULLFSYNC на системах, которые его поддерживают. Значение флага fullfsync по умолчанию — ВЫКЛ. F_FULLFSYNC поддерживается только на Mac OS X.

См. также checkpoint_fullfsync.

PRAGMA function_list;

Эта прагма возвращает список SQL-функций, известных подключению к базе данных. Каждая строка результата описывает одну сигнатуру вызова для одной SQL-функции. Некоторые SQL-функции могут иметь несколько строк в наборе результатов, если, например, они могут вызываться с различным количеством аргументов или могут принимать текст в различных кодировках.

PRAGMA hard_heap_limit
PRAGMA hard_heap_limit=N

Эта прагма вызывает интерфейс sqlite3_hard_heap_limit64() с аргументом N, если N указано и N — положительное целое число, меньшее текущего жесткого предела кучи. Прагма hard_heap_limit всегда возвращает то же целое число, которое вернула бы функция sqlite3_hard_heap_limit64(-1) языка C. То есть она всегда возвращает значение жесткого предела кучи, установленное после любых изменений, внесенных этой прагмой.

Эта прагма может только уменьшать предел кучи, но никогда не увеличивать его. Для увеличения предела кучи необходимо использовать интерфейс языка C sqlite3_hard_heap_limit64().

См. также прагму soft_heap_limit.

PRAGMA ignore_check_constraints = boolean;

Эта прагма включает или отключает выполнение ограничений CHECK. Значение по умолчанию — ВЫКЛ, что означает, что ограничения CHECK по умолчанию выполняются.

PRAGMA schema.incremental_vacuum(N);
PRAGMA schema.incremental_vacuum;

Прагма incremental_vacuum удаляет до N страниц из freelist. Файл базы данных усекается на ту же величину. Прагма incremental_vacuum не имеет эффекта, если база данных не находится в режиме auto_vacuum=incremental или если в freelist нет страниц. Если в freelist меньше N страниц, или если N меньше 1, или если аргумент "(N)" опущен, то весь freelist очищается.

PRAGMA schema.index_info(index-name);

Эта прагма возвращает по одной строке для каждого столбца ключа в указанном индексе. Столбец ключа — это столбец, который фактически указан в операторе CREATE INDEX или UNIQUE constraint или PRIMARY KEY constraint, создавших индекс. Записи индекса обычно также содержат вспомогательные столбцы, указывающие на строку таблицы, индексируемую. Вспомогательные столбцы-индексы не отображаются прагмой index_info, но они перечислены прагмой index_xinfo.

Столбцы вывода из прагмы index_info следующие:

1. Номер столбца в индексе. (0 означает самый левый.)
2. Номер столбца в таблице, которая индексируется. Значение -1 означает rowid, а -2 означает, что используется выражение.
3. Имя столбца, который индексируется. Этот столбец равен NULL, если столбцом является rowid или выражение.

Если нет индекса с именем index-name, но есть таблица WITHOUT ROWID с этим именем, то (начиная с SQLite версии 3.30.0 от 2019-10-04) эта прагма возвращает столбцы PRIMARY KEY таблицы WITHOUT ROWID, как они используются в записях базового B-дерева, то есть с удаленными дублирующимися столбцами.

PRAGMA schema.index_list(table-name);

Эта прагма возвращает по одной строке для каждого индекса, связанного с данной таблицей.

Столбцы вывода из прагмы index_list следующие:

1. Последовательный номер, присвоенный каждому индексу для внутренних целей отслеживания.
2. Имя индекса.
3. "1", если индекс UNIQUE, и "0", если нет.
4. "c", если индекс был создан оператором CREATE INDEX, "u", если индекс был создан ограничением UNIQUE, или "pk", если индекс был создан ограничением PRIMARY KEY.
5. "1", если индекс — частичный индекс, и "0", если нет.

PRAGMA schema.index_xinfo(index-name);

Эта прагма возвращает информацию обо всех столбцах в индексе. В отличие от прагмы index_info, эта прагма возвращает информацию обо всех столбцах в индексе, а не только о столбцах ключа. (Столбец ключа — это столбец, который фактически указан в операторе CREATE INDEX или ограничении UNIQUE или PRIMARY KEY, которые создали индекс. Вспомогательные столбцы — это дополнительные столбцы, необходимые для определения записи таблицы, соответствующей каждой записи индекса.)

Столбцы вывода из прагмы index_xinfo следующие:

1. Номер столбца в индексе. (0 означает самый левый. Столбцы ключа идут перед вспомогательными столбцами.)
2. Номер столбца в таблице, которая индексируется, или -1, если столбец индекса — rowid таблицы, которая индексируется, и -2, если индекс основан на выражении.
3. Имя столбца, который индексируется, или NULL, если столбцом индекса является rowid таблицы, которая индексируется, или выражение.
4. 1, если столбец индекса отсортирован в обратном (DESC) порядке индексом, и 0 в противном случае.
5. Имя используемого сортировочного порядка для сравнения значений в столбце индекса.
6. 1, если столбец — столбец ключа, и 0, если столбец — вспомогательный.

Если нет индекса с именем index-name, но есть таблица WITHOUT ROWID с этим именем, то (начиная с SQLite версии 3.30.0 от 2019-10-04) эта прагма возвращает столбцы таблицы WITHOUT ROWID, как они используются в записях базового B-дерева, то есть с предварительно дедублированными столбцами PRIMARY KEY, за которыми следуют столбцы данных.

PRAGMA schema.integrity_check;
PRAGMA schema.integrity_check(N)
PRAGMA schema.integrity_check(TABLENAME)

Эта прагма выполняет проверку формата и согласованности базы данных на низком уровне. Прагма integrity_check проверяет:

• Записи таблиц или индексов, которые находятся вне последовательности
• Неправильно отформатированные записи
• Отсутствующие страницы
• Отсутствующие или лишние записи индексов
• Ошибки ограничений UNIQUE, CHECK и NOT NULL
• Согласованность freelist
• Разделы базы данных, которые используются более одного раза или вообще не используются

Если прагма integrity_check обнаруживает проблемы, она возвращает строки (в виде нескольких строк с одним столбцом на строку), описывающие эти проблемы. Прагма integrity_check вернёт не более N ошибок перед завершением анализа, при этом N по умолчанию равно 100. Если прагма integrity_check не обнаруживает ошибок, она возвращает одну строку со значением 'ok'.

В обычном случае проверяется весь файл базы данных. Однако, если аргументом является TABLENAME, то проверка выполняется только для указанной таблицы и её связанных индексов. Это называется "частичной проверкой целостности". Поскольку проверяется только подмножество базы данных, ошибки, такие как неиспользуемые разделы файла или использование одного и того же раздела файла двумя или более таблицами, не могут быть обнаружены. Freelist проверяется только при частичной проверке целостности, если TABLENAME равен sqlite_schema или одному из его псевдонимов. Поддержка частичной проверки целостности была добавлена с версией 3.33.0 (2020-08-14).

Прагма integrity_check не находит ошибок FOREIGN KEY. Используйте команду PRAGMA foreign_key_check для поиска ошибок в ограничениях FOREIGN KEY.

См. также команду PRAGMA quick_check, которая выполняет большую часть проверок прагмы integrity_check, но работает значительно быстрее.

PRAGMA schema.journal_mode;
PRAGMA schema.journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF

Эта прагма запрашивает или устанавливает режим журнала для баз данных, связанных с текущим подключением к базе данных.

Первый вариант этой прагмы запрашивает текущий режим журнализации для базы данных. Если база данных опущена, запрашивается "основная" база данных.

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

Режим журнализации DELETE — это стандартное поведение. В режиме DELETE журнал отката удаляется по завершении каждой транзакции. Фактически, операция удаления — это действие, которое приводит к подтверждению транзакции. (См. документ под названием Атомарное подтверждение в SQLite для получения дополнительных подробностей.)

Режим журнализации TRUNCATE подтверждает транзакции, обрезая журнал отката до нулевой длины вместо его удаления. На многих системах обрезка файла намного быстрее, чем его удаление, так как не требуется изменение содержащей его директории.

Режим журнализации PERSIST предотвращает удаление журнала отката в конце каждой транзакции. Вместо этого заголовок журнала перезаписывается нулями. Это предотвратит попытки других подключений к базе данных откатить журнал. Режим журнализации PERSIST полезен в качестве оптимизации на платформах, где удаление или обрезка файла значительно дороже, чем перезапись первого блока файла нулями. См. также: PRAGMA journal_size_limit и SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT.

Режим журнализации MEMORY хранит журнал отката в быстром оперативном запоминающем устройстве (ОЗУ). Это экономит ввод-вывод на диск, но в ущерб безопасности и целостности базы данных. Если приложение, использующее SQLite, аварийно завершается в середине транзакции при установленном режиме журнализации MEMORY, то файл базы данных, скорее всего, повредится.

Режим журнализации WAL использует журнал предварительной записи вместо журнала отката для реализации транзакций. Режим журнализации WAL устойчив; после установки он остается активным для нескольких подключений к базе данных и после закрытия и повторного открытия базы данных. К базе данных в режиме журнализации WAL можно получить доступ только с помощью SQLite версии 3.7.0 (21.07.2010) или более поздней.

Режим журнализации OFF полностью отключает журнал отката. Журнал отката никогда не создается, и, следовательно, его никогда не нужно удалять. Режим журнализации OFF отключает возможности атомарного подтверждения и отката SQLite. Команда ROLLBACK больше не работает; её поведение не определено. Приложения должны избегать использования команды ROLLBACK, когда режим журнала установлен в OFF. Если приложение аварийно завершается в середине транзакции при установленном режиме журнализации OFF, то файл базы данных, скорее всего, повредится. Без журнала нет способа отменить частично выполненные операции после ошибки ограничения. Это также может привести к повреждению базы данных. Например, если дублирующая запись приводит к тому, что операция CREATE UNIQUE INDEX завершается неудачно на полпути, она оставит частично созданный и, следовательно, повреждённый индекс. Поскольку режим журнализации OFF позволяет повредить файл базы данных с помощью обычных SQL-операций, он отключён при включении SQLITE_DBCONFIG_DEFENSIVE.

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

PRAGMA schema.journal_size_limit
PRAGMA schema.journal_size_limit = N ;

Если соединение с базой данных работает в режиме эксклюзивной блокировки или в режиме постоянного журнала (PRAGMA journal_mode=persist), то после подтверждения транзакции файл журнала отката может остаться в файловой системе. Это повышает производительность последующих транзакций, так как перезапись существующего файла быстрее, чем добавление в файл, но также потребляет место в файловой системе. После большой транзакции (например, VACUUM), файл журнала отката может занимать очень большой объём памяти.

Аналогично, в режиме WAL файл журнала предварительной записи не усекается после точки контрольной остановки. Вместо этого SQLite повторно использует существующий файл для последующих записей WAL, так как перезапись быстрее, чем добавление.

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

Вторая форма указанного выше предиката используется для установки нового ограничения в байтах для указанной базы данных. Отрицательное число означает отсутствие ограничения. Чтобы всегда обрезать журналы отката и файлы WAL до их минимального размера, установите journal_size_limit в ноль. Обе формы предиката, указанные выше, возвращают один результат строки, содержащий один целочисленный столбец — значение ограничения размера журнала в байтах. Стандартное ограничение размера журнала — -1 (без ограничения). Макрос препроцессора SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT можно использовать для изменения стандартного ограничения размера журнала во время компиляции.

Этот предикат работает только с единственной базой данных, указанной перед именем предиката (или с «главной» базой данных, если база данных не указана). Нет способа изменить ограничение размера журнала для всех подключенных баз данных с помощью одной команды PRAGMA. Ограничение размера необходимо устанавливать отдельно для каждой подключенной базы данных.

PRAGMA legacy_alter_table;
PRAGMA legacy_alter_table = boolean

Этот предикат устанавливает или запрашивает значение флага legacy_alter_table. При включенном флаге команда ALTER TABLE RENAME (для изменения имени таблицы) работает так же, как и в SQLite 3.24.0 (2018-06-04) и ранее. Более точно, когда этот флаг включен, команда ALTER TABLE RENAME перезаписывает только первое вхождение имени таблицы в операторе CREATE TABLE и в любых связанных операторах CREATE INDEX и CREATE TRIGGER. Другие ссылки на таблицу остаются неизменными, в том числе:

• Ссылки на таблицу внутри тел триггеров и представлений.
• Ссылки на таблицу внутри ограничений CHECK в исходном операторе CREATE TABLE.
• Ссылки на таблицу внутри операторов WHERE в частичных индексах.

Этот предикат предоставляется как обходной путь для старых программ, содержащих код, который ожидает неполного поведения команды ALTER TABLE RENAME, встречающегося в более старых версиях SQLite. Новым приложениям следует оставлять этот флаг выключенным.

Для совместимости со старыми реализациями виртуальных таблиц, этот флаг временно включается во время выполнения метода sqlite3_module.xRename. После завершения метода sqlite3_module.xRename, значение этого флага восстанавливается.

Поведение legacy alter table также может быть включено и выключено с помощью опции SQLITE_DBCONFIG_LEGACY_ALTER_TABLE интерфейса sqlite3_db_config().

Поведение legacy alter table — это настройка на уровне соединения. Включение или выключение этой функции влияет на все подключенные файлы баз данных в рамках соединения с базой данных. Настройка не сохраняется. Изменение этой настройки в одном соединении не влияет на другие соединения.

PRAGMA legacy_file_format;

Этот предикат больше не работает. Он стал пустой операцией. Возможности, ранее предоставляемые PRAGMA legacy_file_format, теперь доступны с помощью опции SQLITE_DBCONFIG_LEGACY_FILE_FORMAT интерфейса C-языка sqlite3_db_config().

PRAGMA schema.locking_mode;
PRAGMA schema.locking_mode = NORMAL | EXCLUSIVE

Этот предикат устанавливает или запрашивает режим блокировки соединения с базой данных. Режим блокировки может быть NORMAL или EXCLUSIVE.

В режиме NORMAL блокировки (по умолчанию, если не переопределено во время компиляции с помощью SQLITE_DEFAULT_LOCKING_MODE) соединение с базой данных разблокирует файл базы данных по завершении каждой транзакции чтения или записи. При установке режима блокировки EXCLUSIVE соединение с базой данных никогда не освобождает блокировки файлов. При первом чтении базы данных в режиме EXCLUSIVE приобретается и удерживается общая блокировка. При первом записи базы данных приобретается и удерживается эксклюзивная блокировка.

Блокировки базы данных, полученные соединением в режиме EXCLUSIVE, могут быть освобождены либо путём закрытия соединения с базой данных, либо путём изменения режима блокировки обратно на NORMAL с помощью этого предиката, а затем доступом к файлу базы данных (для чтения или записи). Простое изменение режима блокировки на NORMAL недостаточно — блокировки не освобождаются до следующего обращения к файлу базы данных.

Существуют три причины для установки режима блокировки в EXCLUSIVE.

1. Приложению необходимо предотвратить доступ к файлу базы данных другим процессам.
2. Сокращается количество системных вызовов для файловых операций, что потенциально может привести к небольшому увеличению производительности.
3. Базы данных WAL могут быть доступны в режиме EXCLUSIVE без использования общей памяти. (Дополнительная информация)

Когда предикат locking_mode указывает конкретную базу данных, например:

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

База данных «temp» (в которой хранятся временные таблицы и индексы) и базы данных в памяти всегда используют режим эксклюзивной блокировки. Режим блокировки для temp и баз данных в памяти изменить нельзя. Все остальные базы данных по умолчанию используют режим нормальной блокировки и на них влияет этот предикат.

Если режим блокировки EXCLUSIVE при первом входе в режим журнализации WAL, то режим блокировки не может быть изменён на NORMAL до выхода из режима журнализации WAL. Если режим блокировки NORMAL при первом входе в режим журнализации WAL, то режим блокировки может быть изменён между NORMAL и EXCLUSIVE и обратно в любое время без необходимости выхода из режима журнализации WAL.

PRAGMA schema.max_page_count;
PRAGMA schema.max_page_count = N;

Задать или получить максимальное количество страниц в файле базы данных. Обе формы оператора PRAGMA возвращают максимальное количество страниц. Вторая форма пытается изменить максимальное количество страниц. Максимальное количество страниц не может быть уменьшено ниже текущего размера базы данных.

PRAGMA schema.mmap_size;
PRAGMA schema.mmap_size=N

Запрос или изменение максимального количества байтов, которые отводятся для ввода-вывода с использованием отображения в памяти для одной базы данных. Первая форма (без аргумента) запрашивает текущее ограничение. Вторая форма (с числовым аргументом) устанавливает ограничение для указанной базы данных или для всех баз данных, если имя базы данных не указано. Во второй форме, если имя базы данных опущено, установленное ограничение становится стандартным для всех баз данных, которые добавляются к соединению с базой данных последующими операторами ATTACH.

Аргумент N — максимальное количество байтов файла базы данных, которое будет обработано с помощью ввода-вывода с отображением в памяти. Если N равно нулю, то ввод-вывод с отображением в памяти отключен. Если N отрицательное, то ограничение восстанавливается до значения по умолчанию, определённого последним вызовом sqlite3_config(SQLITE_CONFIG_MMAP_SIZE), или до значения по умолчанию, определённого во время компиляции, SQLITE_DEFAULT_MMAP_SIZE, если временное ограничение не было установлено.

Оператор PRAGMA mmap_size никогда не увеличивает количество адресного пространства, используемого для ввода-вывода с отображением в памяти, выше жёсткого ограничения, установленного параметром компиляции SQLITE_MAX_MMAP_SIZE, или жёсткого ограничения, установленного во время запуска вторым аргументом sqlite3_config(SQLITE_CONFIG_MMAP_SIZE).

Размер области ввода-вывода с отображением в памяти не может быть изменён, пока область ввода-вывода с отображением в памяти активно используется, чтобы избежать размапирования памяти из-под работающих SQL-запросов. По этой причине оператор PRAGMA mmap_size может быть бесполезным, если предыдущее значение mmap_size ненулевое и в настоящее время выполняются другие SQL-запросы в том же соединении с базой данных.

PRAGMA module_list;

Этот оператор возвращает список зарегистрированных в соединении с базой данных модулей виртуальных таблиц.

PRAGMA optimize;
PRAGMA optimize(MASK);
PRAGMA schema.optimize;
PRAGMA schema.optimize(MASK);

Попытка оптимизировать базу данных. Все схемы оптимизируются в первых двух формах, и только указанная схема оптимизируется в последних двух.

В большинстве приложений использование оператора PRAGMA optimize следующим образом поможет SQLite достичь наилучшей производительности запросов:

1. Приложения с кратковременными соединениями с базой данных должны запускать "PRAGMA optimize;" один раз непосредственно перед закрытием каждого соединения с базой данных.

2. Приложения с долговременными соединениями с базой данных должны запускать "PRAGMA optimize=0x10002;" при первом открытии соединения, а затем периодически запускать "PRAGMA optimize;" — возможно, один раз в день или один раз в час.

3. Все приложения должны запускать "PRAGMA optimize;" после изменения схемы, особенно после одного или нескольких операторов CREATE INDEX.

Этот оператор обычно является бесполезным или почти бесполезным и очень быстрый. В тех случаях, когда ему необходимо выполнить ANALYZE для одной или нескольких таблиц, он устанавливает временное ограничение анализа, действующее только в течение этого оператора PRAGMA, что предотвращает выполнение операций ANALYZE слишком долго.

Рекомендуемой практикой является то, что приложения с кратковременными соединениями с базой данных должны запускать "PRAGMA optimize" один раз при закрытии соединения с базой данных. Приложения с долговременными соединениями с базой данных должны запускать "PRAGMA optimize=0x10002" при первом открытии соединения, а затем запускать "PRAGMA optimize" снова через определённые интервалы — возможно, один раз в день. Все приложения должны запускать "PRAGMA optimize" после изменений схемы, особенно CREATE INDEX.

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

Необязательный аргумент MASK — это битовая маска оптимизаций, которые необходимо выполнить:

По умолчанию MASK равен 0xfffe.

Чтобы увидеть все оптимизации, которые были бы выполнены без их фактического выполнения, запустите "PRAGMA optimize(-1)".

Определение того, когда нужно запускать Analyze

В текущей реализации таблица анализируется только в том случае, если все перечисленные ниже условия являются истинными:

1. Установлен бит MASK 0x02.
2. Таблица является обычной таблицей, а не представлением или виртуальной таблицей.
3. Имя таблицы не начинается с "sqlite_".
4. Выполняется одно или несколько из следующих условий:
   1. Установлен бит 0x10000 MASK
   2. У одного или нескольких индексов таблицы отсутствуют записи в таблице sqlite_stat1.
   3. Планировщик запросов использовал статистику sqlite_stat1 для одного или нескольких индексов этой таблицы в какой-то момент во время работы текущего соединения с базой данных.
5. Выполняется одно или несколько из следующих условий:
   1. У одного или нескольких индексов таблицы отсутствуют записи в таблице sqlite_stat1.
   2. Количество строк в таблице увеличилось или уменьшилось в 10 раз с момента последнего выполнения ANALYZE для таблицы.

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

PRAGMA schema.page_count;

Возвращает общее количество страниц в файле базы данных.

PRAGMA schema.page_size;
PRAGMA schema.page_size = bytes;

Запрос или установка размера страницы базы данных. Размер страницы должен быть степенью двойки в диапазоне от 512 до 65536 включительно.

При создании новой базы данных SQLite назначает размер страницы базе данных на основе платформы и файловой системы. Много лет значение по умолчанию было почти всегда 1024 байта, но начиная с версии SQLite 3.12.0 (29 марта 2016 года) значение по умолчанию увеличилось до 4096. Рекомендуется использовать значение по умолчанию для большинства приложений.

Указание нового размера страницы не меняет размер страницы сразу. Вместо этого новый размер страницы запоминается и используется для установки размера страницы при первом создании базы данных, если она ещё не существует в момент выдачи оператора page_size, или при следующем операторе VACUUM, который выполняется в том же соединении с базой данных, не находясь в режиме WAL.

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

PRAGMA parser_trace = boolean;

Если SQLite скомпилирован с параметром компиляции SQLITE_DEBUG, то оператор PRAGMA parser_trace можно использовать для включения отслеживания для SQL-парсера, используемого внутри SQLite. Эта функция используется для отладки самого SQLite.

Этот оператор предназначен для использования при отладке самого SQLite. Он доступен только при использовании параметра компиляции SQLITE_DEBUG.

PRAGMA pragma_list;

Этот оператор возвращает список команд PRAGMA, известных соединению с базой данных.

PRAGMA query_only;
PRAGMA query_only = boolean;

Оператор query_only предотвращает изменения данных в файлах базы данных при включении. При включении этого оператора любая попытка CREATE, DELETE, DROP, INSERT или UPDATE приведет к ошибке SQLITE_READONLY. Однако база данных не является полностью только для чтения. Вы по-прежнему можете запускать точку проверки или оператор COMMIT, а возвращаемое значение функции sqlite3_db_readonly() не изменится.

PRAGMA schema.quick_check;
PRAGMA schema.quick_check(N)
PRAGMA schema.quick_check(TABLENAME)

Оператор аналогичен integrity_check, за исключением того, что он не проверяет уникальные ограничения и не проверяет соответствие содержимого индекса содержимому таблицы. Пропуская проверки UNIQUE и соответствия индексов, quick_check выполняется быстрее. PRAGMA quick_check выполняется за время O(N), в то время как PRAGMA integrity_check требует времени O(NlogN), где N — общее количество строк в базе данных. В остальных случаях два оператора одинаковы.

PRAGMA read_uncommitted;
PRAGMA read_uncommitted = boolean;

Запрос, установка или сброс изоляции READ UNCOMMITTED. Уровнем изоляции по умолчанию для SQLite является SERIALIZABLE. Любой процесс или поток может выбрать изоляцию READ UNCOMMITTED, но SERIALIZABLE по-прежнему будет использоваться, кроме случаев, когда соединения используют общую страницу и кеш схемы. Обмен кешем включён с помощью API sqlite3_enable_shared_cache(). Обмен кешем по умолчанию выключен.

Дополнительную информацию см. в разделе Режим совместного кэширования SQLite.

PRAGMA recursive_triggers;
PRAGMA recursive_triggers = boolean;

Запрос, установка или сброс возможности рекурсивных триггеров.

Изменение параметра recursive_triggers влияет на выполнение всех операторов, подготовленных с помощью соединения с базой данных, включая те, которые были подготовлены до изменения параметра. Любые существующие операторы, подготовленные с помощью устаревшего интерфейса sqlite3_prepare(), могут завершиться ошибкой SQLITE_SCHEMA после изменения параметра recursive_triggers.

До версии SQLite 3.6.18 (2009-09-11) рекурсивные триггеры не поддерживались. Поведение SQLite всегда было как если бы этот прагма был установлен в OFF. Поддержка рекурсивных триггеров была добавлена в версии 3.6.18, но изначально была выключена по умолчанию для совместимости. Рекурсивные триггеры могут быть включены по умолчанию в будущих версиях SQLite.

Глубина рекурсии для триггеров имеет жесткий верхний предел, установленный опцией компиляции SQLITE_MAX_TRIGGER_DEPTH, и временной предел, установленный sqlite3_limit(db,SQLITE_LIMIT_TRIGGER_DEPTH,...).

PRAGMA reverse_unordered_selects;
PRAGMA reverse_unordered_selects = boolean;

При включении этот PRAGMA заставляет многие операторы SELECT без предложения ORDER BY выводить свои результаты в обратном порядке по сравнению с тем, что они обычно делают. Это может помочь в отладке приложений, которые делают неверные предположения о порядке результатов. Прагма reverse_unordered_selects работает для большинства операторов SELECT, однако планировщик запросов иногда может выбрать алгоритм, который трудно обратить, в этом случае вывод будет отображаться в том же порядке независимо от настройки reverse_unordered_selects.

SQLite не гарантирует порядок результатов, если оператор SELECT опускает предложение ORDER BY. Тем не менее, порядок результатов не меняется от одного выполнения к другому, и поэтому многие приложения ошибочно полагаются на произвольный порядок вывода, каким бы он ни был. Однако иногда новые версии SQLite содержат улучшения оптимизатора, которые могут привести к изменению порядка вывода запросов без предложения ORDER BY. Когда это происходит, приложения, зависящие от определенного порядка вывода, могут работать неправильно. Выполняя приложение несколько раз как с отключенным, так и с включенным этим прагмой, можно выявить и исправить случаи, когда приложение делает ошибочные предположения о порядке вывода, уменьшая проблемы, которые могут быть вызваны подключением к другой версии SQLite.

PRAGMA schema.schema_version;
PRAGMA schema.schema_version = integer ;

Прагма schema_version получит или установит значение целого числа schema-version в смещении 40 в заголовке базы данных.

SQLite автоматически увеличивает schema-version всякий раз, когда изменяется схема. При выполнении каждого оператора SQL проверяется версия схемы, чтобы убедиться, что схема не изменилась с момента подготовки оператора SQL. Обход этой механизма, используя «PRAGMA schema_version=N» для изменения значения schema_version, может привести к выполнению операторов SQL с устаревшей схемой, что может привести к неправильным ответам и/или повреждению базы данных. Чтение schema_version всегда безопасно, но изменение schema_version может вызвать проблемы. По этой причине попытки изменить значение schema_version являются пассивным действием, когда защитный режим включен для подключения к базе данных.

Предупреждение: Неправильное использование этого прагмы может привести к повреждению базы данных.

Для целей этого прагмы команда VACUUM рассматривается как изменение схемы, поскольку VACUUM обычно изменяет значения «rootpage» для записей в таблице sqlite_schema.

См. также прагму application_id и прагму user_version.

PRAGMA schema.secure_delete;
PRAGMA schema.secure_delete = boolean|FAST

Запрос или изменение настройки secure-delete. При включенном secure_delete SQLite перезаписывает удаленное содержимое нулями. Значение по умолчанию для secure_delete определяется опцией компиляции SQLITE_SECURE_DELETE и обычно выключено. Выключенное значение secure_delete повышает производительность, уменьшая количество циклов процессора и объем дисковых операций ввода-вывода. Приложения, которые хотят избежать оставления следов после удаления или обновления содержимого, должны включить прагму secure_delete перед выполнением удаления или обновления, или выполнить VACUUM после удаления или обновления.

Настройка «fast» для secure_delete (добавлен около 2017-08-01) — это промежуточная настройка между «on» и «off». Когда secure_delete установлен в «fast», SQLite перезапишет удалённое содержимое нулями только если это не увеличит объем ввода-вывода. Другими словами, настройка «fast» использует больше циклов процессора, но не использует больше операций ввода-вывода. Это приводит к очистке всего старого содержимого из страниц b-дерева, но оставляют следы на страницах свободного списка.

Когда есть присоединенные базы данных и в прагме не указана база данных, все базы данных изменят свои настройки secure-delete. Настройка secure-delete для вновь присоединенных баз данных — это настройка основной базы данных на момент вычисления команды ATTACH.

Когда несколько подключений к базам данных используют один и тот же кеш, изменение флага secure-delete в одном подключении изменяет его для всех.

Ограничение: Прагма secure_delete заставляет очищать удаленное содержимое только из обычных таблиц. Если виртуальные таблицы хранят содержимое в таблицах-тени, то удаление содержимого из виртуальной таблицы необязательно удаляет следы из таблиц-тени. В частности, виртуальные таблицы FTS3 и FTS5, входящие в состав SQLite, могут оставить следы в своих таблицах-тени, даже если прагма secure_delete включена.

PRAGMA short_column_names;
PRAGMA short_column_names = boolean;

Запрос или изменение флага short-column-names. Этот флаг влияет на способ, которым SQLite называет столбцы данных, возвращаемые операторами SELECT. Полные подробности см. в прагме full_column_names.

Этот прагма устарел и существует только для обратной совместимости. Новые приложения должны избегать использования этого прагмы. Старые приложения должны прекратить его использование как можно скорее. Этот прагма может быть опущен из сборки при компиляции SQLite с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA shrink_memory

Этот прагма заставляет подключение к базе данных, на котором он вызван, освободить как можно больше памяти, вызывая sqlite3_db_release_memory().

PRAGMA soft_heap_limit
PRAGMA soft_heap_limit=N

Этот прагма вызывает интерфейс sqlite3_soft_heap_limit64() с аргументом N, если N указан и является неотрицательным целым числом. Прагма soft_heap_limit всегда возвращает то же целое число, которое возвращала бы функция языка C sqlite3_soft_heap_limit64(-1).

См. также прагму hard_heap_limit.

PRAGMA stats;

Этот прагма возвращает вспомогательную информацию о таблицах и индексах. Возвращаемая информация используется во время тестирования для проверки правильности работы планировщика запросов. Формат и значение этого прагмы, вероятно, будут меняться от одной версии к другой. Из-за своей изменчивости поведение и формат вывода этого прагмы преднамеренно не документированы.

Предполагаемое использование этого прагмы — только для тестирования и проверки SQLite. Этот прагма может быть изменен без предварительного уведомления и не рекомендуется для использования в прикладных программах.

PRAGMA schema.synchronous;
PRAGMA schema.synchronous = 0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA;

Запрос или изменение настройки флага «synchronous». Первая форма (запрос) вернёт настройку synchronous как целое число. Вторая форма изменяет настройку synchronous. Значения различных настроек synchronous следующие:

EXTRA (3)

EXTRA synchronous похож на FULL с добавлением, что директория, содержащая журнал отката rollback journal, синхронизируется после того, как журнал был отсоединен для фиксации транзакции в режиме DELETE. EXTRA предоставляет дополнительную устойчивость, если фиксация происходит сразу после потери питания.

FULL (2)

Когда synchronous равен FULL (2), движок SQLite будет использовать метод xSync VFS для обеспечения того, что все содержимое безопасно запишется на поверхность диска перед продолжением. Это гарантирует, что сбои операционной системы или отключение питания не повредят базу данных. FULL synchronous очень безопасен, но также медленнее. FULL — наиболее часто используемая настройка synchronous, когда не используется режим WAL.

NORMAL (1)

Когда synchronous равен NORMAL (1), движок SQLite все равно будет синхронизироваться в самые критические моменты, но реже, чем в режиме FULL. Существует очень малая (хотя и не нулевая) вероятность того, что отключение питания в неподходящий момент может повредить базу данных в режиме journal_mode=DELETE на старой файловой системе. Режим WAL защищен от повреждения при synchronous=NORMAL, и, вероятно, режим DELETE тоже на современных файловых системах. Режим WAL всегда совместим с synchronous=NORMAL, но режим WAL теряет устойчивость. Транзакция, зафиксированная в режиме WAL с synchronous=NORMAL, может быть отменена после потери питания или сбоя системы. Транзакции устойчивы к сбоям приложений независимо от настройки synchronous или режима журнала.

OFF (0)

При synchronous OFF (0) SQLite продолжает работу без синхронизации, как только передаст данные операционной системе. Если приложение, запускающее SQLite, аварийно завершит работу, данные будут безопасны, но база данных может быть повреждена, если операционная система сбоит или компьютер теряет питание, прежде чем эти данные будут записаны на поверхность диска. С другой стороны, фиксации могут быть на порядки быстрее при synchronous OFF.

В режиме WAL, когда synchronous равен NORMAL (1), файл WAL синхронизируется перед каждой точкой контроля, и файл базы данных синхронизируется после каждой завершенной точки контроля, а заголовок файла WAL синхронизируется, когда файл WAL начинает повторно использоваться после точки контроля, но никаких операций синхронизации не происходит во время большинства транзакций. При synchronous=FULL в режиме WAL происходит дополнительная операция синхронизации файла WAL после каждой фиксации транзакции. Дополнительная синхронизация WAL после каждой транзакции помогает гарантировать устойчивость транзакций при отключении питания. Транзакции согласованы с дополнительными синхронизациями, предоставленными synchronous=FULL или без них. Если устойчивость не является проблемой, то synchronous=NORMAL обычно является всем, что нужно в режиме WAL.

Схема TEMP всегда имеет synchronous=OFF, так как содержимое TEMP является временным и не ожидается, что оно переживет отключение питания. Попытки изменить значение synchronous для TEMP игнорируются без сообщений об ошибках.

См. также прагмы fullfsync и checkpoint_fullfsync.

PRAGMA schema.table_info(table-name);

Эта прагма возвращает одну строку для каждого обычного столбца в указанной таблице. Столбцы в наборе результатов включают: "name" (его имя); "type" (тип данных, если задан, иначе ''); "notnull" (можно ли столбцу присвоить значение NULL); "dflt_value" (значение по умолчанию для столбца); и "pk" (ноль для столбцов, не являющихся частью первичного ключа, или индекс столбца в первичном ключе с началом от 1).

Столбец "cid" не должен интерпретироваться как что-то большее, чем "ранг в текущем наборе результатов".

Таблица, указанная в прагме table_info, также может быть представлением.

Эта прагма не отображает информацию о генерируемых столбцах или скрытых столбцах. Используйте PRAGMA table_xinfo, чтобы получить более полный список столбцов, включая генерируемые и скрытые столбцы.

PRAGMA table_list;
PRAGMA schema.table_list;
PRAGMA table_list(table-name);

Эта прагма возвращает информацию о таблицах и представлениях в схеме, по одной таблице на строку вывода. Прагма table_list впервые появилась в версии SQLite 3.37.0 (2021-11-27). На момент ее первоначального выпуска столбцы, возвращаемые прагмой table_list, включали перечисленные ниже. Будущие версии SQLite, вероятно, добавят дополнительные столбцы вывода.

1. schema: схема, в которой появляется таблица или представление (например, "main" или "temp").
2. name: имя таблицы или представления.
3. type: тип объекта — один из "table", "view", "shadow" (для shadow tables) или "virtual" для virtual tables.
4. ncol: количество столбцов в таблице, включая генерируемые столбцы и скрытые столбцы.
5. wr: 1, если таблица является таблицей WITHOUT ROWID, или 0, если нет.
6. strict: 1, если таблица является STRICT таблицей, или 0, если нет.
7. В будущих версиях, вероятно, будут добавлены дополнительные столбцы.

По умолчанию отображаются все таблицы во всех схемах. Если имя schema. предшествует прагме, отображаются только таблицы в этой схеме. Если задан аргумент table-name, возвращается только информация об этой таблице.

PRAGMA schema.table_xinfo(table-name);

Эта прагма возвращает одну строку для каждого столбца в указанной таблице, включая генерируемые столбцы и скрытые столбцы. Вывод имеет те же столбцы, что и для PRAGMA table_info, плюс столбец "hidden", значение которого указывает на обычный столбец (0), динамический или сохраненный генерируемый столбец (2 или 3) или скрытый столбец в виртуальной таблице (1). Строки, для которых это поле отлично от нуля, исключаются для PRAGMA table_info.

PRAGMA temp_store;
PRAGMA temp_store = 0 | DEFAULT | 1 | FILE | 2 | MEMORY;

Запрос или изменение настройки параметра "temp_store". При temp_store равном DEFAULT (0), макрос препроцессора C SQLITE_TEMP_STORE используется для определения места хранения временных таблиц и индексов. При temp_store равном MEMORY (2) временные таблицы и индексы хранятся так, как если бы они находились в чистых внутрибазовых базах данных. При temp_store равном FILE (1) временные таблицы и индексы хранятся в файле. Прагма temp_store_directory может использоваться для указания каталога, содержащего временные файлы, при использовании FILE. При изменении настройки temp_store все существующие временные таблицы, индексы, триггеры и представления немедленно удаляются.

Возможно, что символ препроцессора C библиотеки SQLITE_TEMP_STORE переопределяет эту настройку прагмы. Следующая таблица обобщает взаимодействие макроса препроцессора SQLITE_TEMP_STORE и прагмы temp_store:

SQLITE_TEMP_STORE	PRAGMA temp_store	Используемый для хранения таблиц TEMP и индексов
0	любой	файл
1	0	файл
1	1	файл
1	2	память
2	0	память
2	1	файл
2	2	память
3	любой	память

PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';

Запрос или изменение значения глобальной переменной sqlite3_temp_directory, которую многие интерфейсы с операционной системой используют для определения места хранения временных таблиц и индексов.

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

Изменение настройки temp_store_directory не является потокобезопасным. Никогда не меняйте настройку temp_store_directory, если другой поток в приложении выполняет какой-либо интерфейс SQLite в то же время. Это приводит к неопределённому поведению. Изменение настройки temp_store_directory записывает значение в глобальную переменную sqlite3_temp_directory, а эта глобальная переменная не защищена с помощью мьютекса.

Значение directory-name должно быть заключено в одинарные кавычки. Для сброса каталога к значению по умолчанию установите directory-name в пустую строку, например, PRAGMA temp_store_directory = ''. Возникает ошибка, если directory-name не найден или не доступен для записи.

Каталог по умолчанию для временных файлов зависит от ОС. Некоторые интерфейсы ОС могут игнорировать эту переменную и помещать временные файлы в другой каталог, отличный от указанного здесь. В этом смысле эта прагма является лишь рекомендательной.

Эта прагма устарела и существует только для обратной совместимости. Новым приложениям следует избегать использования этой прагмы. Более старые приложения должны прекратить использовать эту прагму в ближайшее время. Эта прагма может быть опущена при компиляции SQLite с использованием SQLITE_OMIT_DEPRECATED.

PRAGMA threads;
PRAGMA threads = N;

Запрос или изменение значения ограничения sqlite3_limit(db,SQLITE_LIMIT_WORKER_THREADS,...) для текущего подключения к базе данных. Это ограничение устанавливает верхнюю границу для количества вспомогательных потоков, которые разрешено запускать подготовленному запросу для помощи в выполнении запроса. Значение по умолчанию равно 0, если оно не изменено с помощью параметра времени компиляции SQLITE_DEFAULT_WORKER_THREADS. Когда ограничение равно нулю, это означает, что вспомогательные потоки не будут запущены.

Эта прагма представляет собой тонкий обёртку над интерфейсом sqlite3_limit(db,SQLITE_LIMIT_WORKER_THREADS,...).

PRAGMA trusted_schema;
PRAGMA trusted_schema = boolean;

Настройка trusted_schema — это булевое значение на уровне подключения, определяющее, разрешено ли выполнение SQL-функций и виртуальных таблиц, которые не были проверены на безопасность, представлениями, триггерами или в выражениях схемы, таких как ограничения CHECK, определения DEFAULT, генерируемые столбцы, индексы выражений и/или частичные индексы. Эта настройка также может быть изменена с помощью интерфейса языка C sqlite3_db_config(db,SQLITE_DBCONFIG_TRUSTED_SCHEMA,...).

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

Параметр времени компиляции -DSQLITE_TRUSTED_SCHEMA=0 приведет к тому, что эта настройка будет по умолчанию выключена.

PRAGMA schema.user_version;
PRAGMA schema.user_version = integer ;

Прагма user_version получит или установит значение целочисленной переменной user-version по смещению 60 в заголовке базы данных. User-version — целое число, которое приложения могут использовать по своему усмотрению. SQLite не использует user-version.

См. также прагму application_id и прагму schema_version.

PRAGMA vdbe_addoptrace = boolean;

Если SQLite был скомпилирован с параметром времени компиляции SQLITE_DEBUG, то прагма vdbe_addoptrace может быть использована для вывода полных кодов VDBE, созданных во время генерации кода. Эта функция используется для отладки самого SQLite. Более подробную информацию см. в документации VDBE.

Эта прагма предназначена для использования при отладке самого SQLite. Она доступна только при использовании параметра времени компиляции SQLITE_DEBUG.

PRAGMA vdbe_debug = boolean;

Если SQLite был скомпилирован с параметром времени компиляции SQLITE_DEBUG, то прагма vdbe_debug — это сокращение для трех других прагм, предназначенных только для отладки: vdbe_addoptrace, vdbe_listing и vdbe_trace. Эта функция используется для отладки самого SQLite. Более подробную информацию см. в документации VDBE.

Эта прагма предназначена для использования при отладке самого SQLite. Она доступна только при использовании параметра времени компиляции SQLITE_DEBUG.

PRAGMA vdbe_listing = boolean;

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

Данный оператор предназначен для использования при отладке самого SQLite. Он доступен только при использовании опции компиляции SQLITE_DEBUG.

PRAGMA vdbe_trace = boolean;

Если SQLite скомпилирован с опцией компиляции SQLITE_DEBUG, то с помощью оператора vdbe_trace можно вывести на стандартный вывод команды виртуальной машины по мере их оценки. Эта функция используется для отладки SQLite. Дополнительная информация в документации VDBE.

Данный оператор предназначен для использования при отладке самого SQLite. Он доступен только при использовании опции компиляции SQLITE_DEBUG.

PRAGMA wal_autocheckpoint;
PRAGMA wal_autocheckpoint=N;

Этот оператор запрашивает или устанавливает интервал автоматической проверки точки сохранения журнала записи вперёд. Когда журнал записи вперёд включён (через оператор journal_mode), проверка точки сохранения будет выполняться автоматически всякий раз, когда размер журнала записи вперёд достигает или превышает N страниц. Установка размера автоматической проверки точки сохранения равной нулю или отрицательному значению выключит автоматическую проверку точки сохранения.

Этот оператор является оболочкой для C-интерфейса sqlite3_wal_autocheckpoint(). Все автоматические проверки точки сохранения являются PASSIVE.

Автоматическая проверка точки сохранения включена по умолчанию с интервалом 1000 или SQLITE_DEFAULT_WAL_AUTOCHECKPOINT.

PRAGMA schema.wal_checkpoint;
PRAGMA schema.wal_checkpoint(PASSIVE);
PRAGMA schema.wal_checkpoint(FULL);
PRAGMA schema.wal_checkpoint(RESTART);
PRAGMA schema.wal_checkpoint(TRUNCATE);

Если журнал записи вперёд включён (через оператор journal_mode), этот оператор запускает операцию проверки точки сохранения для базы данных database или для всех присоединённых баз данных, если database опущено. Если режим журнала записи вперёд отключён, этот оператор является безопасной пустой операцией.

Вызов этого оператора без аргумента эквивалентен вызову C-интерфейса sqlite3_wal_checkpoint().

PASSIVE

Проверка точки сохранения как можно большего количества кадров без ожидания завершения работы каких-либо читателей или записывателей баз данных. Синхронизирует файл базы данных, если все кадры в журнале проверены. Этот режим идентичен вызову C-интерфейса sqlite3_wal_checkpoint(). Обработчик ожидания никогда не вызывается в этом режиме.

FULL

Этот режим блокирует (вызывает обратный вызов busy-handler) до тех пор, пока нет записывателей базы данных и все читатели читают из последнего моментального снимка базы данных. Затем он производит проверку точки сохранения всех кадров в файле журнала и синхронизирует файл базы данных. FULL блокирует одновременных записывателей во время выполнения, но читатели могут продолжить работу.

RESTART

Этот режим работает так же, как FULL, с добавлением того, что после проверки точки сохранения файла журнала он блокируется (вызывает обратный вызов busy-handler) до завершения работы всех читателей с файлом журнала. Это гарантирует, что следующий клиент, записывающий в файл базы данных, перезапустит файл журнала с начала. RESTART блокирует одновременных записывателей во время выполнения, но читатели могут продолжить работу.

TRUNCATE

Этот режим работает так же, как RESTART, с добавлением того, что файл WAL усекается до нуля байтов после успешного завершения.

Оператор wal_checkpoint возвращает одну строку с тремя целочисленными столбцами. Первый столбец обычно равен 0, но будет равен 1, если проверка точки сохранения RESTART или FULL или TRUNCATE не смогла завершиться, например, потому что другая нить или процесс активно использовали базу данных. Иными словами, первый столбец равен 0, если эквивалентный вызов sqlite3_wal_checkpoint_v2() вернул SQLITE_OK, или 1, если эквивалентный вызов вернул SQLITE_BUSY. Второй столбец — количество измененных страниц, которые были записаны в файл журнала записи вперёд. Третий столбец — количество страниц в файле журнала записи вперёд, которые были успешно перемещены обратно в файл базы данных по окончании проверки точки сохранения. Второй и третий столбцы равны -1, если нет журнала записи вперёд, например, если этот оператор вызывается по подключению к базе данных, которое не находится в режиме WAL.

PRAGMA writable_schema = boolean;
PRAGMA writable_schema = RESET

Когда этот оператор включён, и флаг SQLITE_DBCONFIG_DEFENSIVE отключён, то таблицу sqlite_schema можно изменять с помощью обычных операторов UPDATE, INSERT и DELETE. Если аргумент равен "RESET", то запись схемы отключается (как с "PRAGMA writable_schema=OFF") и, кроме того, схема перезагружается. Предупреждение: неправильное использование этого оператора может легко привести к повреждению файла базы данных.

Последнее изменение этой страницы 27 августа 2024 г. 10:16:11 UTC