INDEXED BY
SQL As Understood By SQLite
[Top]
INDEXED BY
INDEXED BY 短语强制 SQLite 查询规划器在 DELETE，SELECT 或 UPDATE 语句上使用特定的命名索引。INDEXED BY 短语是 SQLite 扩展，不能移植到其他 SQL 数据库引擎。
qualified-table-name: hide
“INDEXED BY 索引名称 ”短语指定必须使用已命名的索引才能查找上表中的值。如果索引名称不存在或不能用于查询，则 SQL 语句的准备将失败。“NOT INDEXED” 子句指定访问上表时不应使用索引，包括由 UNIQUE和PRIMARY KEY 约束创建的隐含索引。但是，即使指定了 “NOT INDEXED”，rowid 仍可用于查找条目。
一些 SQ L数据库引擎提供了非标准的“提示”机制，可以用来为查询优化器提供关于应该为特定语句使用哪些索引的线索。SQLite 的 INDEX BY 子句不是一个提示机制，不应该这样使用。INDEXED BY 子句不给优化器提示使用哪个索引; 它为优化器提供了使用哪个索引的要求。如果查询优化器无法使用由 INDEX BY 子句指定的索引，则查询将失败并出现错误。
INDEXED BY 子句不适用于调整查询的性能。INDEXED BY 子句的意图是，如果模式更改（如删除或创建索引）导致查询计划更改时间敏感查询，则会引发运行时错误。INDEXED BY 子句旨在帮助检测回归测试期间不需要的查询计划更改。应用程序开发人员被告诫在应用程序设计，实现，测试和调优期间省略所有 INDEXED BY 的使用。如果要使用 INDEXED BY，则应在开发过程的最后插入“锁定”设计。
可以参阅：
- 查询规划人员清单描述了应用程序开发人员应该遵循的步骤，以帮助解决查询规划问题。请注意，INDEXED BY 的使用是最后的手段，只有在所有其他措施失败时才能使用。
- 一元“+”运算符可用于使 WHERE 子句中的术语不被索引使用。谨慎使用一元+有时可以帮助防止查询计划人员选择不良索引而不将其限制为使用一个特定索引。仔细放置一元+运算符是控制查询使用哪些索引的更好方法。
- sqlite3_stmt_status（）C / C ++ 接口连同 SQLITE_STMTSTATUS_FULLSCAN_STEP 和 SQLITE_STMTSTATUS_SORT 动词可用于在运行时检测SQL语句未有效使用索引的情况。许多应用程序可能更喜欢使用 sqlite3_stmt_status（）接口来检测索引滥用，而不是这里描述的 INDEXED BY 短语。
