Small. Fast. Reliable.
Choose any three.
Choose any three.
PRAGMA语句是特定于SQLite的SQL扩展，用于修改SQLite库的操作或查询SQLite库的内部（非表）数据。PRAGMA语句是使用与其他SQLite命令（例如SELECT，INSERT）相同的接口发出的，但在以下重要方面有所不同：
用于SQLite的C语言API提供了SQLITE_FCNTL_PRAGMA 文件控件，该控件使VFS实现可以添加新的PRAGMA语句或覆盖内置PRAGMA语句的含义。
编译指示可以采用零或一个参数。参数可以在括号中，也可以与编译指示名称以等号分隔。这两种语法产生相同的结果。在许多编译指示中，该参数是布尔值。布尔值可以是以下之一：
关键字参数可以选择用引号引起来。（例如： 'yes'[FALSE]。）某些编译指示将字符串文字作为其自变量。当编译指示采用关键字参数时，通常也将采用数值等效项。例如，“ 0”和“否”与“ 1”和“是”的含义相同。查询设置的值时，许多编译指示会返回数字而不是关键字。
编译指示可以 在编译指示名称之前具有可选的架构名称。该架构名称是一个企业的名称ATTACH主和TEMP数据库-ed数据库或“主”或“临时”。如果省略了可选的架构名称，则假定为“ main”。在某些语用上，模式名称是没有意义的，只是被忽略。在下面的文档中，模式名称有意义的编译指示以“ schema。 ”前缀显示。
可以从普通的SELECT语句作为表值函数访问返回结果且没有副作用的PRAGMA 。对于每个参与的PRAGMA，对应的表值函数的名称与PRAGMA的名称相同，前缀为7个字符。PRAGMA参数和模式（如果有）作为参数传递给表值函数。
例如，可以使用index_info杂指令读取有关索引中列的信息，如下所示：
PRAGMA index_info（'idx52'）;
或者，可以使用以下命令读取相同的内容：
选择* FROM pragma_index_info（'idx52'）;
表值函数格式的优点是查询可以仅返回PRAGMA列的子集，可以包含WHERE子句，可以使用聚合函数，而表值函数可以只是表中多个数据源之一。加入。例如，要获取模式中所有索引列的列表，可以查询：
SELECT DISTINCT m.name || '。' || ii.AS为“索引列”
从sqlite_schema AS m，
pragma_index_list（m.name）如il，
pragma_index_info（il.name）AS ii
在哪里m.type ='table'
ORDER BY 1;
补充笔记：
表值函数仅适用于内置PRAGMA，不适用于使用SQLITE_FCNTL_PRAGMA文件控件定义的PRAGMA。
表值函数仅适用于返回结果且没有副作用的PRAGMA。
通过首先使用以下方法创建单独的架构， 可以使用此功能来实现 信息架构：
然后创建 的意见在该模式实现使用表值函数PRAGMA的官方信息模式表。ATTACH '：memory：'AS'information_schema';
此功能是实验性的，随时可能更改。如果PRAGMAs功能的表值函数得到正式支持，将提供进一步的文档。
PRAGMA功能的表值函数已在SQLite版本3.16.0（2017-01-02）中添加。SQLite的早期版本不能使用此功能。
笔记：
PRAGMA analysis_limit;
PRAGMA analysis_limit = N ;
查询或更改ANALYZE近似设置的限制。这是ANALYZE命令在每个索引中检查的大约行数。如果参数N如果省略，则分析极限不变。如果限制为零，则禁用分析限制，并且ANALYZE命令将检查每个索引的所有行。如果N大于零，则将分析限制设置为N，并且随后的ANALYZE命令将在检查了大约N行后停止分析每个索引。如果N为负数或除整数以外的其他值，则杂注的行为就像忽略了N参数一样。在所有情况下，返回的值都是用于后续ANALYZE命令的新分析限制。
此实用程序可用于帮助ANALYZE命令在大型数据库上更快地运行。当仅检查每个索引的一部分时，分析结果并不理想，但结果通常足够好。将N设置为100或1000可以使ANALYZE命令非常快速地运行，即使是在数千兆字节的数据库文件上也是如此。此实用程序与PRAGMA优化结合使用时特别有用。
此实用程序是在SQLite版本3.32.0（2020-05-22）中添加的。当前实现仅使用N值的低31位-静默忽略高位。未来版本的SQLite可能会开始使用更高阶的位。
PRAGMA模式。application_id;
PRAGMA模式。application_id =整数；
application_id PRAGMA用于查询或将位于偏移量68的32位带符号大端“应用程序ID”整数设置到数据库头中。使用SQLite作为其 应用程序文件格式的应用程序应将Application ID整数设置为唯一的整数，以便诸如file（1）之类的实用程序 可以确定特定的文件类型，而不仅仅是报告“ SQLite3数据库”。通过查询SQLite源存储库中的magic.txt文件，可以看到已分配的应用程序ID的列表 。
另请参阅user_version编译指示。
PRAGMA模式。auto_vacuum;
PRAGMA模式。auto_vacuum =
0 | 无| 1 | 满| 2 | 增量;
在数据库中查询或设置自动真空状态。
除非使用SQLITE_DEFAULT_AUTOVACUUM编译时选项，否则自动真空的默认设置为0或“无” 。“无”设置表示禁用自动真空。禁用自动真空并且从数据库中删除数据后，数据库文件将保持相同大小。未使用的数据库文件页面被添加到“ freelist ”中，并用于后续插入。因此，不会丢失数据库文件空间。但是，数据库文件不会收缩。在这种模式下，VACUUM 命令可用于重建整个数据库文件，从而回收未使用的磁盘空间。
当自动真空模式为1或“完全”时，空闲列表页面将移至数据库文件的末尾，并且在每次事务提交时，数据库文件将被截断以删除空闲列表页面。但是请注意，自动清理只会截断文件中的空闲列表页面。自动真空不会像VACUUM命令那样对数据库进行碎片整理或重新打包单个数据库页面 。实际上，由于自动抽真空会在文件内四处移动页面，因此实际上会使碎片变得更糟。
仅当数据库存储了一些其他信息，这些信息允许将每个数据库页面追溯到其引荐来源时，才可以进行自动抽真空。因此，在创建任何表之前必须打开自动真空。创建表后，无法启用或禁用自动真空。
当auto-vacuum的值为2或“ incremental”时，进行自动真空处理所需的其他信息存储在数据库文件中，但是自动提交不会像auto_vacuum = full那样在每次提交时自动发生。在增量模式下，必须调用单独的 增量变量_pragma才能引起自动真空发生。
可以随时在完全自动和增量自动真空模式之间更改数据库连接。但是，仅当数据库是新数据库（尚未创建表）或通过运行VACUUM命令时，才可能从“无”更改为“完整”或“增量” 。要更改自动真空模式，请首先使用auto_vacuum编译指示设置所需的新模式，然后调用VACUUM命令重新组织整个数据库文件。要从“完全”或“增量”变回“无”，即使在空数据库上也始终需要运行VACUUM。
当不带任何参数调用auto_vacuum编译指示时，它将返回当前的auto_vacuum模式。
PRAGMA automatic_index;
PRAGMA automatic_index =布尔值；
查询，设置或清除自动索引功能。
从3.7.17（2013-05-20）版本开始，默认情况下会启用 自动索引，但是在将来的SQLite版本中可能会更改。
PRAGMA busy_timeout;
PRAGMA busy_timeout =毫秒；
查询或更改繁忙超时的设置 。该编译指示是sqlite3_busy_timeout（） C语言接口的替代方法，该接口可用作编译指示，可用于不直接访问sqlite3_busy_timeout（）的语言绑定。
每个数据库连接只能有一个 繁忙的处理程序。此PRAGMA设置进程的繁忙处理程序，可能会覆盖任何先前设置的繁忙处理程序。
PRAGMA模式。cache_size;
PRAGMA模式。cache_size =页数；
PRAGMA模式。cache_size =-千字节;
查询或更改每个打开的数据库文件一次SQLite将在内存中保留的数据库磁盘页面的建议最大数目。应用程序定义的页面缓存将决定是否接受此建议 。内置在SQLite中的默认页面缓存会接受该请求，但是，其他应用程序定义的页面缓存实现可以选择以不同的方式解释建议的缓存大小，或者将其全部忽略。建议的默认高速缓存大小为-2000，这意味着高速缓存大小限制为2048000字节的内存。可以使用SQLITE_DEFAULT_CACHE_SIZE编译时选项来更改默认的建议缓存大小 。TEMP数据库的默认建议缓存大小为0页。
如果参数N为正，则建议的缓存大小设置为N。如果参数N为负，则将缓存页数调整为将使用大约abs（N * 1024）字节内存的页数。根据当前页面大小。SQLite会记住页面缓存中的页面数，而不是所使用的内存量。因此，如果您使用负数设置高速缓存大小，然后更改页面大小（使用 PRAGMA page_size命令），则高速缓存的最大数量将根据页面大小的变化而增加或减少。
向后兼容性说明：版本3.7.10（2012-01-16） 之前具有负N的cache_size的行为不同。在早期版本中，缓存中的页面数设置为N的绝对值。
当您使用cache_size编译指示更改缓存大小时，该更改仅在当前会话中有效。关闭并重新打开数据库后，缓存大小将恢复为默认值。
默认的页面缓存实现不会一次分配全部的缓存内存。高速缓存在需要时按较小的块分配。page_cache设置是（建议的）上限，用于缓存可以使用的内存量，而不是缓存将一直使用的内存量。这是默认页面高速缓存实现的行为，但是 应用程序定义的页面高速缓存可以随意改变行为。
PRAGMA cache_spill;
PRAGMA cache_spill =布尔值;
PRAGMA模式。cache_spill = N ;
cache_spill编译指示启用或禁用分页器在事务中间将脏的缓存页面溢出到数据库文件的功能。默认情况下，Cache_spill是启用的，并且大多数应用程序都应该采用这种方式，因为缓存溢出通常是有利的。但是，缓存溢出具有获取数据库文件上的EXCLUSIVE锁的副作用 。因此，某些具有大量长时间运行的事务的应用程序可能希望禁用缓存溢出，以防止该应用程序在事务COMMIT之前获得对数据库的排他锁。
此编译指示的“ PRAGMA cache_spill = N ”形式设置发生溢出所需的最小高速缓存大小阈值。高速缓存中的页面数必须同时超过cache_spill阈值和PRAGMA cache_size语句设置的最大高速缓存大小，才能发生溢出。
该编译指示的“ PRAGMA cache_spill = boolean ”形式适用于连接到数据库连接的所有数据库。但是此语句的“ PRAGMA cache_spill = N ”形式仅适用于“主”模式或该语句中指定的任何其他模式。
PRAGMA case_sensitive_like =布尔值；
LIKE运算符的默认行为是忽略ASCII字符的大小写。因此，默认情况下，“ a”（如“ A”）为true。case_sensitive_like编译指示将安装一个新的应用程序定义的LIKE函数，该函数区分大小写或不区分大小写，具体取决于case_sensitive_like编译指示的值。禁用case_sensitive_like时，将表示默认的LIKE行为。启用case_sensitive_like时，大小写变得很重要。因此，例如， “ a”（如“ A”）为假，但“ a”（如“ a”）仍为真。
该编译指示使用sqlite3_create_function（）重载LIKE和GLOB函数，这可能会覆盖应用程序注册的LIKE和GLOB的先前实现。此编译指示仅更改SQL LIKE运算符的行为。它不会更改sqlite3_strlike（） C语言接口的行为，该行为始终不区分大小写。
PRAGMA cell_size_check
PRAGMA cell_size_check =布尔值；
当最初从磁盘读取数据库b树页面时，cell_size_check编译指示启用或禁用对数据库b树页面的其他完整性检查。启用单元格大小检查后，可以更早地检测到数据库损坏，并且不太可能“扩散”。但是，进行额外的检查对性能影响不大，因此默认情况下将禁用像元大小检查。
PRAGMA checkpoint_fullfsync
PRAGMA checkpoint_fullfsync =布尔值；
查询或更改checkpoint操作的fullfsync标志。如果设置了此标志，则在支持F_FULLFSYNC的系统上的检查点操作期间将使用F_FULLFSYNC同步方法。checkpoint_fullfsync标志的默认值是off。仅Mac OS-X支持F_FULLFSYNC。
如果设置了fullfsync标志，则F_FULLFSYNC同步方法将用于所有同步操作，而checkpoint_fullfsync设置是不相关的。
PRAGMA collation_list;
返回为当前数据库连接定义的整理序列的列表。
PRAGMA compile_options;
此编译指示返回在构建SQLite时使用的编译时选项的名称，每行一个选项。返回的选项名称中省略了“ SQLITE_”前缀。另请参见 sqlite3_compileoption_get（） C / C ++接口和 sqlite_compileoption_get（） SQL函数。
PRAGMA count_changes;
PRAGMA count_changes =布尔值；
查询或更改计数更改标志。通常，当未设置count-changes标志时，INSERT，UPDATE和DELETE语句不返回任何数据。设置计数更改后，这些命令中的每条命令都返回一行数据，该数据由一个整数值组成-该命令插入，修改或删除的行数。返回的更改计数不包括触发器执行的任何插入，修改或删除，外键操作自动进行的任何更改或upsert引起的更新。
获取行更改计数的另一种方法是使用 sqlite3_changes（）或sqlite3_total_changes（）接口。但是，有一个细微的不同。当使用INSTEAD OF触发器对视图运行INSERT，UPDATE或DELETE时，count_changes编译指示将报告触发该触发器的视图中的行数，而sqlite3_changes（）和 sqlite3_total_changes（）则不会。
不建议使用此编译指示，并且该编译指示仅用于向后兼容。新的应用程序应避免使用此编译指示。较旧的应用程序应尽早停止使用该实用程序。使用SQLITE_OMIT_DEPRECATED编译SQLite时，可以从构建中省略此编译指示。
PRAGMA data_store_directory;
PRAGMA data_store_directory ='目录名';
查询或更改sqlite3_data_directory全局变量的值，Windows操作系统接口后端使用该变量来确定使用相对路径名指定的数据库文件的存储位置。
更改data_store_directory设置不是线程安全的。如果应用程序中的另一个线程正在同时运行任何SQLite接口，则切勿更改data_store_directory设置。这样做会导致未定义的行为。更改data_store_directory设置将写入sqlite3_data_directory全局变量，并且该全局变量不受互斥锁的保护。
此功能是为WinRT提供的，它不具有用于读取或更改当前工作目录的OS机制。不建议在任何其他情况下使用该实用程序，并且在将来的发行版中可能会禁止使用该实用程序。
不建议使用此编译指示，并且该编译指示仅用于向后兼容。新的应用程序应避免使用此编译指示。较旧的应用程序应尽早停止使用该实用程序。使用SQLITE_OMIT_DEPRECATED编译SQLite时，可以从构建中省略此编译指示。
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 data_version”值才有意义。
PRAGMA database_list;
此实用程序的作用就像查询一样，为连接到当前数据库连接的每个数据库返回一行。第二列是用于主数据库文件的“ main”，用于存储TEMP对象的数据库文件的“ temp”，或用于其他数据库文件的ATTACHed数据库的名称。第三列是数据库文件本身的名称，如果数据库未与文件关联，则为空字符串。
此编译指示查询或设置建议为每个打开的数据库文件分配的最大磁盘高速缓存页数。此编译指示与cache_size之间的区别在于，此处设置的值在数据库连接之间保持不变。默认高速缓存大小的值存储在数据库文件头中偏移量48处的4字节big-endian整数中。
不建议使用此编译指示，并且该编译指示仅用于向后兼容。新的应用程序应避免使用此编译指示。较旧的应用程序应尽早停止使用该实用程序。使用SQLITE_OMIT_DEPRECATED编译SQLite时，可以从构建中省略此编译指示。
PRAGMA defer_foreign_keys
PRAGMA defer_foreign_keys =布尔值；
当defer_foreign_keys PRAGMA处于打开状态时，所有外键约束的实施都将延迟，直到最外面的事务被提交为止。defer_foreign_keys编译指示默认为OFF，因此仅当将外键约束创建为“ DEFERRABLE INITIALIALLY DEFERRED”时才将其推迟。在每个COMMIT或ROLLBACK处，defer_foreign_keys编译指示都会自动关闭。因此，必须为每个事务分别启用defer_foreign_keys编译指示。当然，只有在启用了外键约束的情况下，这种编译指示才有意义。
该sqlite3_db_status（DB，SQLITE_DBSTATUS_DEFERRED_FKS，...）C语言界面，可以在交易期间使用，以确定是否有延迟和未解决的外键约束。
PRAGMA empty_result_callbacks;
PRAGMA empty_result_callbacks =布尔值;
查询或更改empty-result-callbacks标志。
empty-result-callbacks标志仅影响sqlite3_exec（） API。通常，当清除empty-result-callbacks标志时，不会为返回零数据行的命令调用提供给sqlite3_exec（）的回调函数。在这种情况下，如果设置了Empty-result-callbacks，则将回调函数仅调用一次，第三个参数设置为0（NULL）。这是为了使使用sqlite3_exec（） API的程序即使在查询不返回任何数据时也可以检索列名。
不建议使用此编译指示，并且该编译指示仅用于向后兼容。新的应用程序应避免使用此编译指示。较旧的应用程序应尽早停止使用该实用程序。使用SQLITE_OMIT_DEPRECATED编译SQLite时，可以从构建中省略此编译指示。
PRAGMA编码；
PRAGMA编码='UTF-8';
PRAGMA编码='UTF-16';
PRAGMA编码='UTF-16le';
PRAGMA编码='UTF-16be';
在第一种形式中，如果已经创建了主数据库，则此编译指示将返回主数据库使用的文本编码，即'UTF-8'，'UTF-16le'（小尾数UTF-16编码）或' UTF-16be”（Big-endian UTF-16编码）。如果尚未创建主数据库，则返回的值是将用于创建主数据库的文本编码（如果此会话已创建）。
此编译指示的第二种形式到第五种形式设置了如果通过此会话创建主数据库将使用的编码。字符串'UTF-16'被解释为“使用本地机器字节顺序的UTF-16编码”。创建数据库后，无法更改其文本编码，并且任何尝试都会被忽略。
如果未首先使用此编译指示设置编码，则用于创建主数据库的编码默认为用于打开连接的API所确定的编码 。
一旦为数据库设置了编码，就无法更改它。
ATTACH命令创建的数据库始终使用与主数据库相同的编码。尝试使用与“主”数据库不同的文本编码来附加数据库的尝试将失败。
PRAGMA模式。foreign_key_check;
PRAGMA模式。foreign_key_check（table-name ）;
foreign_key_check杂注检查数据库或称为“ table-name ”的表是否违反了 外键约束。Foreign_key_check编译指示针对每种外键违规返回一行输出。每个结果行有四列。第一列是包含REFERENCES子句的表的名称。第二列是包含无效REFERENCES子句的行的rowid；如果子表是WITHOUT ROWID，则为NULL 桌子。第三列是所引用表的名称。第四列是失败的特定外键约束的索引。在foreign_key_check编译指示的输出处的第四列是相同的整数作为输出的第一列foreign_key_list编译。当指定了“ table-name ”时，检查的唯一外键约束是由CREATE TABLE语句中的table-name的REFERENCES子句创建的约束。
PRAGMA foreign_key_list（table-name ）;
对于 由“表名”表的CREATE TABLE语句中的REFERENCES子句创建的每个外键约束，此编译指示均返回一行。
PRAGMA外键；
PRAGMA foreign_keys =布尔值;
查询，设置或清除外键约束的执行。
这种语用是交易中的禁忌。仅当没有待处理的BEGIN或SAVEPOINT时，才可以启用或禁用外键约束强制 。
更改foreign_keys设置会影响使用数据库连接准备的所有语句的执行，包括更改设置之前准备的语句。更改foreign_keys设置后，使用旧版sqlite3_prepare（）接口准备的任何现有语句都 可能因SQLITE_SCHEMA错误而失败。
从SQLite 3.6.19版本开始，外键强制的默认设置为OFF。但是，这可能会在将来的SQLite版本中发生变化。可以在编译时使用SQLITE_DEFAULT_FOREIGN_KEYS 预处理程序宏指定外键强制的默认设置。为了最大程度地减少将来的问题，应用程序应根据应用程序的要求设置外键强制标志，而不应依赖于默认设置。
PRAGMA模式。freelist_count;
返回数据库文件中未使用的页数。
PRAGMA full_column_names;
PRAGMA full_column_names =布尔值;
查询或更改full_column_names标志。此标志与short_column_names标志一起确定SQLite将名称分配给SELECT语句的结果列的方式。通过按顺序应用以下规则来命名结果列：
如果结果上有一个AS子句，则该列的名称位于AS子句的右侧。
如果结果是通用表达式，而不仅仅是源表列的名称，那么结果的名称就是表达式文本的副本。
如果short_column_names编译指示为ON，则结果的名称为没有源表名称前缀COLUMN的源表列的名称。
如果编译指示short_column_names和full_column_names 都为OFF，则情况（2）适用。
结果列的名称是源表和源列名称的组合：TABLE.COLUMN
不建议使用此编译指示，并且该编译指示仅用于向后兼容。新的应用程序应避免使用此编译指示。较旧的应用程序应尽早停止使用该实用程序。使用SQLITE_OMIT_DEPRECATED编译SQLite时，可以从构建中省略此编译指示。
PRAGMA fullfsync
PRAGMA fullfsync =布尔值；
查询或更改fullfsync标志。此标志确定F_FULLFSYNC同步方法是否在支持该方法的系统上使用。fullfsync标志的默认值是off。仅Mac OS X支持F_FULLFSYNC。
另请参阅checkpoint_fullfsync。
PRAGMA function_list;
该编译指示返回数据库连接已知的SQL函数的列表。结果的每一行都描述了单个SQL函数的单个调用签名。如果某些SQL函数（例如）可以用不同数量的参数调用或可以接受各种编码的文本，则它们在结果集中将具有多行。
PRAGMA hard_heap_limit
PRAGMA hard_heap_limit = N
如果指定了N且N是小于当前硬堆限制的正整数，则该编译指示使用参数N调用sqlite3_hard_heap_limit64（）接口。hard_heap_limit杂注总是返回与sqlite3_hard_heap_limit64（-1）C语言函数返回的整数相同的整数。也就是说，它总是返回在此PRAGMA施加的任何更改之后设置的硬堆限制的值。
此编译指示只能降低堆限制，而不能提高堆限制。必须使用C语言接口sqlite3_hard_heap_limit64（）来提高堆限制。
另请参阅soft_heap_limit杂注。
PRAGMA ignore_check_constraints =布尔值;
此实用程序启用或禁用CHECK约束的执行。默认设置为off，这意味着默认情况下会强制执行CHECK约束。
PRAGMA模式。增量真空（N）;
PRAGMA模式。增量真空;
incremental_vacuum用法导致从空闲列表中最多删除N个页面。数据库文件将被截断相同的数量。如果数据库不在auto_vacuum = incremental模式下，或者在空闲列表中没有页面，则cremental_vacuum编译指示无效 。如果空闲列表上的页面少于 N，或者N小于1，或者省略了“（N）”参数，则将清除整个空闲列表。
PRAGMA模式。index_info（index-name ）;
该编译指示为命名索引中的每个键列返回一行。键列是在创建索引的CREATE INDEX 索引语句或UNIQUE约束或PRIMARY KEY约束中实际命名的列。索引条目通常还包含辅助列，这些辅助列指向要建立索引的表行。辅助索引列未由index_info编译指示显示，但由index_xinfo编译指示列出。
index_info用法的输出列如下：
如果没有名为index-name的索引，但是有一个具有该名称的 WITHOUT ROWID表，则（从2019-10-04开始，SQLite版本3.30.0）此pragma返回它们的WITHOUT ROWID表的PRIMARY KEY列。用于基础b树的记录中，也就是说，删除了重复的列。
PRAGMA模式。index_list（table-name ）;
该编译指示为与给定表关联的每个索引返回一行。
index_list编译指示的输出列如下：
PRAGMA模式。index_xinfo（index-name ）;
该编译指示返回有关索引中每一列的信息。与index_info杂注不同，此杂注返回有关索引中每一列的信息，而不仅仅是键列。（键列是在创建索引的CREATE INDEX 索引语句或UNIQUE约束或PRIMARY KEY约束中实际命名的列。辅助列是查找与每个索引条目相对应的表条目所需的其他列。）
index_xinfo用法的输出列如下：
如果没有名为index-name的索引，但有一个具有该名称的 WITHOUT ROWID表，则（从2019-10-04开始，SQLite版本3.30.0起），此编译指示将返回使用时WITHOUT ROWID表的列在基础b树的记录中，也就是说先删除重复数据的PRIMARY KEY列，然后再添加data列。
PRAGMA模式。完整性检查;
PRAGMA模式。integrity_check（N ）
PRAGMA模式。完整性检查（TABLENAME ）
此编译指示对数据库进行低级格式化和一致性检查。integrity_check编译指示寻找：
如果integration_check杂注发现问题，则返回描述问题的字符串（多行，每行一列）。在 退出分析之前，Pragma integrity_check将最多返回N个错误，N默认为100。如果pragma integrity_check没有发现错误，则返回值为'ok'的一行。
通常情况是检查整个数据库文件。但是，如果参数为TABLENAME，则仅对命名表及其关联的索引执行检查。这称为“部分完整性检查”。因为仅检查数据库的一个子集，所以无法检测到错误，例如文件的未使用节或两个或多个表重复使用文件的同一节。如果TABLENAME是sqlite_schema或其别名之一，则仅在部分完整性检查中验证自由列表。版本3.33.0（2020-08-14）中添加了对部分完整性检查的支持。
PRAGMA integrity_check找不到 FOREIGN KEY错误。使用PRAGMA foreign_key_check命令查找FOREIGN KEY约束中的错误。
另请参阅PRAGMA quick_check命令，该命令执行PRAGMA完整性检查的大部分检查，但运行速度更快。
PRAGMA模式。journal_mode;
PRAGMA模式。journal_mode =删除| 截断 持久性| 内存| 沃尔| 离开
此编译指示查询或设置与当前数据库连接关联的数据库的日志模式。
此编译指示的第一种形式查询数据库的当前日记记录模式。当数据库被省略，“主”查询数据库。
如果省略了“数据库”，则第二种形式将更改“数据库”或所有附加数据库的日志记录模式。返回新的日记模式。如果日记模式无法更改，则返回原始日记模式。
删除日记记录模式是正常行为。在DELETE模式下，回滚日志在每个事务结束时被删除。实际上，删除操作是导致事务提交的操作。（有关其他详细信息，请参见标题为“ SQLite中的原子提交”的文档。）
TRUNCATE日记记录模式通过将回滚日记帐截断为零长度而不是将其删除来提交事务。在许多系统上，截断文件比删除文件快得多，因为不需要更改包含目录。
PERSIST日志记录模式可防止在每个事务结束时删除回滚日志。而是，日记的标题被零覆盖。这将防止其他数据库连接回滚日志。PERSIST日记模式在平台上的优化非常有用，在该平台上，删除或截断文件比用零覆盖文件的第一块要贵得多。另请参阅： PRAGMA journal_size_limit和SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT。
MEMORY日记记录模式将回滚日记记录存储在易失性RAM中。这样可以节省磁盘I / O，但要以牺牲数据库安全性和完整性为代价。如果在设置MEMORY日记模式时使用SQLite的应用程序在事务中间崩溃，则数据库文件很可能 会损坏。
WAL日记模式使用预写日志而不是回滚日记来实现事务。WAL日记记录模式是持久的；设置后，它在多个数据库连接中有效，并且在关闭并重新打开数据库后仍然有效。只能通过SQLite 3.7.0版（2010-07-21）或更高版本访问处于WAL日记模式的数据库。
OFF日志记录模式完全禁用回滚日志记录。不会创建回滚日志，因此永远不会删除回滚日志。OFF日志记录模式禁用SQLite的原子提交和回滚功能。该ROLLBACK命令不再有效; 它的行为方式不确定。当日志模式为OFF时，应用程序必须避免使用ROLLBACK命令。如果在设置OFF日记模式的情况下应用程序在事务中间崩溃，则数据库文件很可能 会损坏。没有日志，语句将无法在约束错误之后展开部分完成的操作。这也可能使数据库处于损坏状态。例如，如果重复条目导致 CREATE UNIQUE INDEX语句中途失败，它将留下部分创建的索引，因此该索引已损坏。因为OFF日记模式允许使用普通SQL破坏数据库文件，所以在启用SQLITE_DBCONFIG_DEFENSIVE时将其禁用。
请注意，内存数据库的journal_mode为 MEMORY或OFF，并且不能将其更改为其他值。将内存数据库的journal_mode更改为除MEMORY或OFF以外的任何设置的尝试都将被忽略。还请注意，事务处于活动状态时，不能更改journal_mode。
PRAGMA模式。journal_size_limit
PRAGMA模式。journal_size_limit = N ;
如果数据库连接以 互斥锁定模式或 持久日志模式 （PRAGMA journal_mode = persist）运行，则在提交事务后，回滚日志文件可能会保留在文件系统中。由于覆盖现有文件的速度比追加到文件的速度要快，因此这可以提高后续事务的性能，但同时也会占用文件系统空间。在进行大量事务（例如VACUUM）之后，回滚日志文件可能会占用大量空间。
同样，在WAL模式下，预写日志文件不会在checkpoint之后被截断。相反，由于重写比附加操作快，因此SQLite会将现有文件重用于后续的WAL条目。
journal_size_limit杂注可用于限制事务或检查点之后留在文件系统中的rollback-journal和WAL文件的大小。每次提交事务或重置WAL文件时，SQLite都会将文件系统中剩余的回滚日志文件或WAL文件的大小与此编译指示设置的大小限制进行比较，如果日志或WAL文件较大，则会将其截断到极限。
上面列出的编译指示的第二种形式用于为指定的数据库设置新的限制（以字节为单位）。负数表示没有限制。要始终将回滚日志和WAL文件截断为最小大小，请将journal_size_limit设置为零。上面列出的编译指示的第一种和第二种形式都返回包含单个整数列的单个结果行-日志大小限制的值（以字节为单位）。默认的日记帐大小限制为-1（无限制）。该 SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT预处理宏可以用来在编译时更改默认的日志大小限制。
此编译指示仅对在编译指示名之前指定的单个数据库起作用（如果未指定数据库，则对“主”数据库起作用）。无法使用单个PRAGMA语句更改所有连接数据库的日志大小限制。必须为每个连接的数据库分别设置大小限制。
PRAGMA legacy_alter_table;
PRAGMA legacy_alter_table =布尔值
该编译指示设置或查询legacy_alter_table标志的值。启用此标志时，ALTER TABLE RENAME 命令（用于更改表的名称）的工作方式与SQLite 3.24.0（2018-06-04）及更早版本中的工作相同。更具体地说，当此标志位于ALTER TABLE RENAME命令上时，仅在其CREATE TABLE语句以及任何关联的 CREATE INDEX和CREATE TRIGGER语句中重写表名的初始出现。对该表的其他引用未经修改，包括：
提供此杂项作为变通方法，用于较旧的程序，其中包含的代码预期在较旧版本的SQLite中发现ALTER TABLE RENAME的行为不完整。新应用程序应将此标志保持关闭状态。
为了与较旧的虚拟表实现兼容， 在运行sqlite3_module.xRename方法时，将暂时打开此标志。在sqlite3_module.xRename方法完成后，将还原此标志的值 。
也可以使用sqlite3_db_config（）接口的SQLITE_DBCONFIG_LEGACY_ALTER_TABLE选项来 打开和关闭旧版alter table行为。
旧版alter table行为是每个连接的设置。启用或禁用此功能会影响数据库连接中所有附加的数据库文件 。设置不会持续。在一个连接中更改此设置不会影响任何其他连接。
PRAGMA legacy_file_format;
该编译指示不再起作用。它已成为无人值守。以前由PRAGMA legacy_file_format提供的功能现在可以通过sqlite3_db_config（） C语言界面的SQLITE_DBCONFIG_LEGACY_FILE_FORMAT 选项使用。
PRAGMA模式。锁定模式;
PRAGMA模式。锁定模式=正常| 独家的
此编译指示设置或查询数据库连接锁定模式。锁定模式为NORMAL或EXCLUSIVE。
在NORMAL锁定模式下（默认值，除非使用SQLITE_DEFAULT_LOCKING_MODE在编译时进行覆盖，否则为默认值），在每次读取或写入事务结束时，数据库连接都会解锁数据库文件。当锁定模式设置为EXCLUSIVE时，数据库连接从不释放文件锁。第一次在EXCLUSIVE模式下读取数据库时，将获取并保留一个共享锁。第一次写入数据库时，将获得并保留一个排他锁。
通过关闭数据库连接，或通过使用此编译指示将锁定模式设置回NORMAL，然后访问数据库文件（用于读取或写入），可以释放通过EXCLUSIVE模式下的连接获得的数据库锁。仅仅将锁定模式设置为NORMAL是不够的-直到下次访问数据库文件时，才会释放锁定。
将锁定模式设置为EXCLUSIVE的三个原因。
当locking_mode编译指示指定特定的数据库时，例如：
PRAGMA主营。locking_mode =排他性;
然后，锁定模式仅适用于命名数据库。如果在“ locking_mode”关键字之前没有数据库名称限定符，则锁定模式将应用于所有数据库，包括由后续ATTACH命令添加的任何新数据库。
“ temp”数据库（存储TEMP表和索引的数据库）和内存数据库 始终使用互斥锁定模式。临时数据库和内存数据库的锁定模式 无法更改。默认情况下，所有其他数据库都使用普通锁定模式，并且受此编译指示的影响。
如果在首次进入WAL日志模式时锁定模式为EXCLUSIVE ，则只有在退出WAL日志模式后才能将锁定模式更改为NORMAL。如果在首次进入WAL日志模式时锁定模式为NORMAL，则可以在NORMAL和EXCLUSIVE之间更改锁定模式，然后随时退出，而无需退出WAL日志模式。
PRAGMA模式。max_page_count;
PRAGMA模式。max_page_count = N ;
查询或设置数据库文件中的最大页面数。两种形式的编译指示都返回最大页数。第二种形式试图修改最大页数。最大页面数不能减少到当前数据库大小以下。
PRAGMA模式。mmap_size;
PRAGMA模式。mmap_size = N
查询或更改为单个数据库上的内存映射I / O预留的最大字节数。第一种形式（不带参数）查询当前限制。第二种形式（带有数字参数）设置指定数据库或所有数据库（如果省略了可选数据库名称）的限制。在第二种形式中，如果省略数据库名称，则设置的限制将成为通过后续ATTACH 语句添加到数据库连接中的所有数据库的默认限制。
参数N是将使用内存映射的I / O访问的数据库文件的最大字节数。如果N为零，则禁用内存映射的I / O。如果N为负，则该限制将恢复为由最新sqlite3_config（SQLITE_CONFIG_MMAP_SIZE）确定的默认值 ，或者恢复为由SQLITE_DEFAULT_MMAP_SIZE确定的编译时间默认值（如果未设置开始时间限制）。
所述PRAGMA mmap_size语句将永远不会增加用于地址空间量存储器映射的I / O上述由硬限制集合SQLITE_MAX_MMAP_SIZE编译时的选择，也没有硬限制设定起动时由第二个参数sqlite3_config（SQLITE_CONFIG_MMAP_SIZE）
内存映射的I / O区域处于活动状态时，不能更改内存映射的I / O区域的大小，以避免在正在运行的SQL语句中取消内存的映射。因此，如果先前的mmap_size不为零，并且在同一数据库连接上同时运行其他SQL语句，则mmap_size编译指示可能为空 。
PRAGMA module_list;
该编译指示返回在数据库连接中注册的虚拟表模块的列表 。
PRAGMA优化；
PRAGMA优化（MASK ）;
PRAGMA模式.optimize;
PRAGMA模式.optimize（MASK ）;
尝试优化数据库。所有方案都以前两种形式进行了优化，只有指定的方案以后两种形式进行了优化。
为了获得最佳的长期查询性能，而无需对应用程序模式和SQL进行详细的工程分析，建议在关闭每个数据库连接之前，应用程序运行“ PRAGMAoptimize”（不带参数）。长时间运行的应用程序还可以通过设置计时器每隔几个小时运行一次“ PRAGMA优化”而受益。
此实用程序通常是无操作的或几乎是无操作的，并且非常快。但是，如果SQLite认为执行数据库优化（例如运行ANALYZE 或创建新索引）将提高未来查询的性能，则可以完成一些数据库I / O。想要限制执行的工作量的应用程序可以设置一个计时器，如果编译指示进行的时间过长，该计时器将调用 sqlite3_interrupt（）。或者，从SQLite 3.32.0开始，应用程序可以将 PRAGMA analysis_limit = N用作较小的N值（几百或几千），以限制分析的深度。
预期此实用程序执行的优化的详细信息会随着时间的推移而变化和改进。应用程序应预期此实用程序将在将来的版本中执行新的优化。
可选的MASK参数是要执行的优化的位掩码：
调试模式。实际不执行任何优化，而是为要执行的每个优化返回一行文本。默认情况下关闭。
在可能会受益的表上 运行ANALYZE。默认情况下为开。有关其他信息，请参见下文。
（尚未实现） 将当前会话的使用情况和性能信息记录在数据库文件中，以便可用于“优化”由将来的数据库连接运行的编译指示。
（尚未实现） 创建可能对最近的查询有用的索引。
默认的MASK始终为0xfffe。0xfffe掩码表示执行上面列出的所有优化（调试模式除外）。如果将来添加了默认情况下应禁用的新优化，则这些新优化的掩码将设置为0x10000或更大。
要查看无需实际执行即可完成的所有优化，请运行“ PRAGMAoptimize（-1）”。要仅使用ANALYZE优化，请运行“ PRAGMAoptimize（0x02）”。
确定何时运行分析
在当前实现中，当且仅当以下所有条件都为真时，才分析表：
MASK位0x02设置为1。
查询计划程序在当前连接的生存期内的某个时候对表的一个或多个索引使用了sqlite_stat1样式的统计信息。
表中的一个或多个索引目前未分析或 自上次及时分析已运行行的表中的数量已经增加了25倍以上。
The rules for when tables are analyzed are likely to change in future releases.
PRAGMA schema.page_count;
Return the total number of pages in the database file.
PRAGMA schema.page_size;
PRAGMA schema.page_size = bytes;
Query or set the page size of the database. The page size must be a power of two between 512 and 65536 inclusive.
When a new database is created, SQLite assigns a page size to the database based on platform and filesystem. For many years, the default page size was almost always 1024 bytes, but beginning with SQLite version 3.12.0 (2016-03-29), the default page size increased to 4096. The default page size is recommended for most applications.
Specifying a new page size does not change the page size immediately. Instead, the new page size is remembered and is used to set the page size when the database is first created, if it does not already exist when the page_size pragma is issued, or at the next VACUUM command that is run on the same database connection while not in WAL mode.
The SQLITE_DEFAULT_PAGE_SIZE compile-time option can be used to change the default page size assigned to new databases.
PRAGMA parser_trace = boolean;
If SQLite has been compiled with the SQLITE_DEBUG compile-time option, then the parser_trace pragma can be used to turn on tracing for the SQL parser used internally by SQLite. This feature is used for debugging SQLite itself.
This pragma is intended for use when debugging SQLite itself. It is only available when the SQLITE_DEBUG compile-time option is used.
PRAGMA pragma_list;
This pragma returns a list of PRAGMA commands known to the database connection.
PRAGMA query_only;
PRAGMA query_only = boolean;
The query_only pragma prevents data changes on database files when enabled. When this pragma is enabled, any attempt to CREATE, DELETE, DROP, INSERT, or UPDATE will result in an SQLITE_READONLY error. However, the database is not truly read-only. You can still run a checkpoint or a COMMIT and the return value of the sqlite3_db_readonly() routine is not affected.
PRAGMA schema.quick_check;
PRAGMA schema.quick_check(N)
PRAGMA schema.quick_check(TABLENAME)
The pragma is like integrity_check except that it does not verify UNIQUE constraints and does not verify that index content matches table content. By skipping UNIQUE and index consistency checks, quick_check is able to run faster. PRAGMA quick_check runs in O(N) time whereas PRAGMA integrity_check requires O(NlogN) time where N is the total number of rows in the database. Otherwise the two pragmas are the same.
PRAGMA read_uncommitted;
PRAGMA read_uncommitted = boolean;
Query, set, or clear READ UNCOMMITTED isolation. The default isolation level for SQLite is SERIALIZABLE. Any process or thread can select READ UNCOMMITTED isolation, but SERIALIZABLE will still be used except between connections that share a common page and schema cache. Cache sharing is enabled using the sqlite3_enable_shared_cache() API. Cache sharing is disabled by default.
See SQLite Shared-Cache Mode for additional information.
PRAGMA recursive_triggers;
PRAGMA recursive_triggers = boolean;
Query, set, or clear the recursive trigger capability.
Changing the recursive_triggers setting affects the execution of all statements prepared using the database connection, including those prepared before the setting was changed. Any existing statements prepared using the legacy sqlite3_prepare() interface may fail with an SQLITE_SCHEMA error after the recursive_triggers setting is changed.
Prior to SQLite version 3.6.18 (2009-09-11), recursive triggers were not supported. The behavior of SQLite was always as if this pragma was set to OFF. Support for recursive triggers was added in version 3.6.18 but was initially turned OFF by default, for compatibility. Recursive triggers may be turned on by default in future versions of SQLite.
The depth of recursion for triggers has a hard upper limit set by the SQLITE_MAX_TRIGGER_DEPTH compile-time option and a run-time limit set by sqlite3_limit(db,SQLITE_LIMIT_TRIGGER_DEPTH,...).
PRAGMA reverse_unordered_selects;
PRAGMA reverse_unordered_selects = boolean;
When enabled, this PRAGMA causes many SELECT statements without an ORDER BY clause to emit their results in the reverse order from what they normally would. This can help debug applications that are making invalid assumptions about the result order. The reverse_unordered_selects pragma works for most SELECT statements, however the query planner may sometimes choose an algorithm that is not easily reversed, in which case the output will appear in the same order regardless of the reverse_unordered_selects setting.
SQLite makes no guarantees about the order of results if a SELECT omits the ORDER BY clause. Even so, the order of results does not change from one run to the next, and so many applications mistakenly come to depend on the arbitrary output order whatever that order happens to be. However, sometimes new versions of SQLite will contain optimizer enhancements that will cause the output order of queries without ORDER BY clauses to shift. When that happens, applications that depend on a certain output order might malfunction. By running the application multiple times with this pragma both disabled and enabled, cases where the application makes faulty assumptions about output order can be identified and fixed early, reducing problems that might be caused by linking against a different version of SQLite.
PRAGMA schema.schema_version;
PRAGMA schema.schema_version = integer ;
The schema_version pragma will get or set the value of the schema-version integer at offset 40 in the database header.
SQLite automatically increments the schema-version whenever the schema changes. As each SQL statement runs, the schema version is checked to ensure that the schema has not changed since the SQL statement was prepared. Subverting this mechanism by using "PRAGMA schema_version" may cause SQL statement to run using an obsolete schema, which can lead to incorrect answers and/or database corruption.
Warning: Misuse of this pragma can result in database corruption.
For the purposes of this pragma, the VACUUM command is considered a schema change, since VACUUM will usual alter the "rootpage" values for entries in the sqlite_schema table.
See also the application_id pragma and user_version pragma.
PRAGMA schema.secure_delete;
PRAGMA schema.secure_delete = boolean|FAST
Query or change the secure-delete setting. When secure_delete is on, SQLite overwrites deleted content with zeros. The default setting for secure_delete is determined by the SQLITE_SECURE_DELETE compile-time option and is normally off. The off setting for secure_delete improves performance by reducing the number of CPU cycles and the amount of disk I/O. Applications that wish to avoid leaving forensic traces after content is deleted or updated should enable the secure_delete pragma prior to performing the delete or update, or else run VACUUM after the delete or update.
The "fast" setting for secure_delete (added circa 2017-08-01) is an intermediate setting in between "on" and "off". When secure_delete is set to "fast", SQLite will overwrite deleted content with zeros only if doing so does not increase the amount of I/O. In other words, the "fast" setting uses more CPU cycles but does not use more I/O. This has the effect of purging all old content from b-tree pages, but leaving forensic traces on freelist pages.
When there are attached databases and no database is specified in the pragma, all databases have their secure-delete setting altered. The secure-delete setting for newly attached databases is the setting of the main database at the time the ATTACH command is evaluated.
When multiple database connections share the same cache, changing the secure-delete flag on one database connection changes it for them all.
PRAGMA short_column_names;
PRAGMA short_column_names = boolean;
Query or change the short-column-names flag. This flag affects the way SQLite names columns of data returned by SELECT statements. See the full_column_names pragma for full details.
This pragma is deprecated and exists for backwards compatibility only. New applications should avoid using this pragma. Older applications should discontinue use of this pragma at the earliest opportunity. This pragma may be omitted from the build when SQLite is compiled using SQLITE_OMIT_DEPRECATED.
PRAGMA shrink_memory
This pragma causes the database connection on which it is invoked to free up as much memory as it can, by calling sqlite3_db_release_memory().
PRAGMA soft_heap_limit
PRAGMA soft_heap_limit=N
This pragma invokes the sqlite3_soft_heap_limit64() interface with the argument N, if N is specified and is a non-negative integer. The soft_heap_limit pragma always returns the same integer that would be returned by the sqlite3_soft_heap_limit64(-1) C-language function.
See also the hard_heap_limit pragma.
PRAGMA stats;
This pragma returns auxiliary information about tables and indices. The returned information is used during testing to help verify that the query planner is operating correctly. The format and meaning of this pragma will likely change from one release to the next. Because of its volatility, the behavior and output format of this pragma are deliberately undocumented.
The intended use of this pragma is only for testing and validation of SQLite. This pragma is subject to change without notice and is not recommended for use by application programs.
PRAGMA schema.synchronous;
PRAGMA schema.synchronous =
0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA;
Query or change the setting of the "synchronous" flag. The first (query) form will return the synchronous setting as an integer. The second form changes the synchronous setting. The meanings of the various synchronous settings are as follows:
In WAL mode when synchronous is NORMAL (1), the WAL file is synchronized before each checkpoint and the database file is synchronized after each completed checkpoint and the WAL file header is synchronized when a WAL file begins to be reused after a checkpoint, but no sync operations occur during most transactions. With synchronous=FULL in WAL mode, an additional sync operation of the WAL file happens after each transaction commit. The extra WAL sync following each transaction help ensure that transactions are durable across a power loss. Transactions are consistent with or without the extra syncs provided by synchronous=FULL. If durability is not a concern, then synchronous=NORMAL is normally all one needs in WAL mode.
The TEMP schema always has synchronous=OFF since the content of of TEMP is ephemeral and is not expected to survive a power outage. Attempts to change the synchronous setting for TEMP are silently ignored.
See also the fullfsync and checkpoint_fullfsync pragmas.
PRAGMA schema.table_info(table-name);
This pragma returns one row for each column in the named table. Columns in the result set include the column name, data type, whether or not the column can be NULL, and the default value for the column. The "pk" column in the result set is zero for columns that are not part of the primary key, and is the index of the column in the primary key for columns that are part of the primary key.
The table named in the table_info pragma can also be a view.
See also: PRAGMA table_xinfo
PRAGMA schema.table_xinfo(table-name);
This pragma returns one row for each column in the named table, including hidden columns in virtual tables. The output is the same as for PRAGMA table_info except that hidden columns are shown rather than being omitted.
PRAGMA temp_store;
PRAGMA temp_store =
0 | DEFAULT | 1 | FILE | 2 | MEMORY;
Query or change the setting of the "temp_store" parameter. When temp_store is DEFAULT (0), the compile-time C preprocessor macro SQLITE_TEMP_STORE is used to determine where temporary tables and indices are stored. When temp_store is MEMORY (2) temporary tables and indices are kept in as if they were pure in-memory databases memory. When temp_store is FILE (1) temporary tables and indices are stored in a file. The temp_store_directory pragma can be used to specify the directory containing temporary files when FILE is specified. When the temp_store setting is changed, all existing temporary tables, indices, triggers, and views are immediately deleted.
It is possible for the library compile-time C preprocessor symbol SQLITE_TEMP_STORE to override this pragma setting. The following table summarizes the interaction of the SQLITE_TEMP_STORE preprocessor macro and the temp_store pragma:
SQLITE_TEMP_STORE PRAGMA
temp_storeStorage used for
TEMP tables and indices0 any file 1 0 file 1 1 file 1 2 memory 2 0 memory 2 1 file 2 2 memory 3 any memory
PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';
Query or change the value of the sqlite3_temp_directory global variable, which many operating-system interface backends use to determine where to store temporary tables and indices.
When the temp_store_directory setting is changed, all existing temporary tables, indices, triggers, and viewers in the database connection that issued the pragma are immediately deleted. In practice, temp_store_directory should be set immediately after the first database connection for a process is opened. If the temp_store_directory is changed for one database connection while other database connections are open in the same process, then the behavior is undefined and probably undesirable.
Changing the temp_store_directory setting is not threadsafe. Never change the temp_store_directory setting if another thread within the application is running any SQLite interface at the same time. Doing so results in undefined behavior. Changing the temp_store_directory setting writes to the sqlite3_temp_directory global variable and that global variable is not protected by a mutex.
The value directory-name should be enclosed in single quotes. To revert the directory to the default, set the directory-name to an empty string, e.g., PRAGMA temp_store_directory = ''. An error is raised if directory-name is not found or is not writable.
The default directory for temporary files depends on the OS. Some OS interfaces may choose to ignore this variable and place temporary files in some other directory different from the directory specified here. In that sense, this pragma is only advisory.
This pragma is deprecated and exists for backwards compatibility only. New applications should avoid using this pragma. Older applications should discontinue use of this pragma at the earliest opportunity. This pragma may be omitted from the build when SQLite is compiled using SQLITE_OMIT_DEPRECATED.
PRAGMA threads;
PRAGMA threads = N;
Query or change the value of the sqlite3_limit(db,SQLITE_LIMIT_WORKER_THREADS,...) limit for the current database connection. This limit sets an upper bound on the number of auxiliary threads that a prepared statement is allowed to launch to assist with a query. The default limit is 0 unless it is changed using the SQLITE_DEFAULT_WORKER_THREADS compile-time option. When the limit is zero, that means no auxiliary threads will be launched.
This pragma is a thin wrapper around the sqlite3_limit(db,SQLITE_LIMIT_WORKER_THREADS,...) interface.
PRAGMA trusted_schema;
PRAGMA trusted_schema = boolean;
The trusted_schema setting is a per-connection boolean that determines whether or not SQL functions and virtual tables that have not been security audited are allowed to be run by views, triggers, or in expressions of the schema such as CHECK constraints, DEFAULT clauses, generated columns, expression indexes, and/or partial indexes. This setting can also be controlled using the sqlite3_db_config(db,SQLITE_DBCONFIG_TRUSTED_SCHEMA,...) C-language interface.
In order to maintain backwards compatibility, this setting is ON by default. There are advantages to turning it off, and most applications will be unaffected if it is turned off. For that reason, all applications are encouraged to switch this setting off on every database connection as soon as that connection is opened.
The -DSQLITE_TRUSTED_SCHEMA=0 compile-time option will cause this setting to default to OFF.
PRAGMA schema.user_version;
PRAGMA schema.user_version = integer ;
The user_version pragma will to get or set the value of the user-version integer at offset 60 in the database header. The user-version is an integer that is available to applications to use however they want. SQLite makes no use of the user-version itself.
See also the application_id pragma and schema_version pragma.
PRAGMA vdbe_addoptrace = boolean;
If SQLite has been compiled with the SQLITE_DEBUG compile-time option, then the vdbe_addoptrace pragma can be used to cause a complete VDBE opcodes to be displayed as they are created during code generation. This feature is used for debugging SQLite itself. See the VDBE documentation for more information.
This pragma is intended for use when debugging SQLite itself. It is only available when the SQLITE_DEBUG compile-time option is used.
PRAGMA vdbe_debug = boolean;
If SQLite has been compiled with the SQLITE_DEBUG compile-time option, then the vdbe_debug pragma is a shorthand for three other debug-only pragmas: vdbe_addoptrace, vdbe_listing, and vdbe_trace. This feature is used for debugging SQLite itself. See the VDBE documentation for more information.
This pragma is intended for use when debugging SQLite itself. It is only available when the SQLITE_DEBUG compile-time option is used.
PRAGMA vdbe_listing = boolean;
If SQLite has been compiled with the SQLITE_DEBUG compile-time option, then the vdbe_listing pragma can be used to cause a complete listing of the virtual machine opcodes to appear on standard output as each statement is evaluated. With listing is on, the entire content of a program is printed just prior to beginning execution. The statement executes normally after the listing is printed. This feature is used for debugging SQLite itself. See the VDBE documentation for more information.
This pragma is intended for use when debugging SQLite itself. It is only available when the SQLITE_DEBUG compile-time option is used.
PRAGMA vdbe_trace = boolean;
If SQLite has been compiled with the SQLITE_DEBUG compile-time option, then the vdbe_trace pragma can be used to cause virtual machine opcodes to be printed on standard output as they are evaluated. This feature is used for debugging SQLite. See the VDBE documentation for more information.
This pragma is intended for use when debugging SQLite itself. It is only available when the SQLITE_DEBUG compile-time option is used.
PRAGMA wal_autocheckpoint;
PRAGMA wal_autocheckpoint=N;
This pragma queries or sets the write-ahead log auto-checkpoint interval. When the write-ahead log is enabled (via the journal_mode pragma) a checkpoint will be run automatically whenever the write-ahead log equals or exceeds N pages in length. Setting the auto-checkpoint size to zero or a negative value turns auto-checkpointing off.
This pragma is a wrapper around the sqlite3_wal_autocheckpoint() C interface. All automatic checkpoints are PASSIVE.
Autocheckpointing is enabled by default with an interval of 1000 or 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);
If the write-ahead log is enabled (via the journal_mode pragma), this pragma causes a checkpoint operation to run on database database, or on all attached databases if database is omitted. If write-ahead log mode is disabled, this pragma is a harmless no-op.
不带参数调用此编译指示等效于调用 sqlite3_wal_checkpoint（） C接口。
使用参数调用此编译指示等效于使用与参数 对应的第三个参数调用 sqlite3_wal_checkpoint_v2（） C接口 ：The wal_checkpoint pragma returns a single row with three integer columns. The first column is usually 0 but will be 1 if a RESTART or FULL or TRUNCATE checkpoint was blocked from completing, for example because another thread or process was actively using the database. In other words, the first column is 0 if the equivalent call to sqlite3_wal_checkpoint_v2() would have returned SQLITE_OK or 1 if the equivalent call would have returned SQLITE_BUSY. The second column is the number of modified pages that have been written to the write-ahead log file. The third column is the number of pages in the write-ahead log file that have been successfully moved back into the database file at the conclusion of the checkpoint. The second and third column are -1 if there is no write-ahead log, for example if this pragma is invoked on a database connection that is not in WAL mode.
PRAGMA writable_schema = boolean;
When this pragma is on, and the SQLITE_DBCONFIG_DEFENSIVE flag is off, then the sqlite_schema table can be changed using ordinary UPDATE, INSERT, and DELETE statements. Warning: misuse of this pragma can easily result in a corrupt database file.