1. INDEXED BY 的工作原理

INDEXED BY 短语强制 SQLite 查询规划器 在 DELETE、SELECT 或 UPDATE 语句中使用特定的命名索引。INDEXED BY 短语是 SQLite 的扩展，不能移植到其他 SQL 数据库引擎。

限定表名 隐藏

"INDEXED BY 索引名" 短语指定必须使用命名的索引来查找前一个表上的值。如果 索引名 不存在或无法用于查询，则 SQL 语句的准备将失败。"NOT INDEXED" 子句指定在访问前一个表时不应使用任何索引，包括由 UNIQUE 和 PRIMARY KEY 约束创建的隐式索引。但是，即使指定了 "NOT INDEXED"，仍然可以使用 rowid 来查找条目。

一些 SQL 数据库引擎提供非标准的“提示”机制，可用于向查询优化器提供有关它应该为特定语句使用哪些索引的线索。SQLite 的 INDEXED BY 子句不是提示机制，不应将其用作提示机制。INDEXED BY 子句不会向优化器提供有关使用哪个索引的提示；它向优化器提供必须使用哪个索引的要求。如果查询优化器无法使用 INDEXED BY 子句指定的索引，则查询将失败并出现错误。

INDEXED BY 子句并非旨在用于调整查询的性能。INDEXED BY 子句的目的是在架构更改（例如删除或创建索引）导致时间敏感查询的查询计划发生更改时引发运行时错误。INDEXED BY 子句旨在帮助在回归测试期间检测不需要的查询计划更改。建议应用程序开发人员在应用程序设计、实现、测试和调整期间省略所有 INDEXED BY 的使用。如果要使用 INDEXED BY，则应在开发过程的最后阶段“锁定”设计时插入它。

2. 另请参阅

1. 查询规划器检查列表 描述了应用程序开发人员应遵循的步骤，以帮助解决查询规划器问题。请注意，使用 INDEXED BY 是最后的手段，仅在所有其他措施都失败时才使用。

2. 一元“+”运算符 可用于取消 WHERE 子句中术语的索引使用资格。谨慎使用一元 + 有时可以帮助防止查询规划器选择不良索引，而无需将其限制为使用一个特定索引。谨慎放置一元 + 运算符是控制查询使用哪些索引的更好方法。

3. sqlite3_stmt_status() C/C++ 接口以及 SQLITE_STMTSTATUS_FULLSCAN_STEP 和 SQLITE_STMTSTATUS_SORT 动词可用于在运行时检测 SQL 语句何时未有效利用索引。许多应用程序可能更喜欢使用 sqlite3_stmt_status() 接口来检测索引误用，而不是此处描述的 INDEXED BY 短语。

此页面上次修改于 2022-01-08 05:02:57 UTC