Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Remove obsolete statements from the EXPLAIN QUERY PLAN documentation. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
735ffb4d2d2578c19d94d7304defc00a |
| User & Date: | drh 2017-02-04 14:45:16 |
Context
|
2017-02-04
| ||
| 15:16 | Updates to the change log for 3.17.0. check-in: 90822d4b15 user: drh tags: trunk | |
| 14:45 | Remove obsolete statements from the EXPLAIN QUERY PLAN documentation. check-in: 735ffb4d2d user: drh tags: trunk | |
|
2017-02-03
| ||
| 04:10 | Clarify wording about PRAGMA synchronous=NORMAL and WAL mode. check-in: 7660cac647 user: drh tags: trunk | |
Changes
Changes to pages/eqp.in.
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 |
^(<codeblock>
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SCAN TABLE t1
</codeblock>)^
<p>
The example above shows
SQLite estimating that the full-table scan will visit approximately
100,000 records. If the query were able to use an index, then the
SCAN/SEARCH record would include the name of the index and, for a
SEARCH record, an indication of how the subset of rows visited is
identified. For example:
^(<codeblock>
sqlite> CREATE INDEX i1 ON t1(a);
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SEARCH TABLE t1 USING INDEX i1
</codeblock>)^
<p>
The previous example, SQLite uses index "i1" to optimize
a WHERE clause term of the form (a=?) - in this case "a=1". SQLite
estimates that about 10 records will match the "a=1" term.
The previous example could not use a [covering index], but the following
example can, and that fact is reflected in the output:
^(<codeblock>
sqlite> CREATE INDEX i2 ON t1(a, b);
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?)
</codeblock>)^
|
| | | < |
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 |
^(<codeblock>
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SCAN TABLE t1
</codeblock>)^
<p>
The example above shows
SQLite picking full-table scan will visit all rows in the table.
If the query were able to use an index, then the
SCAN/SEARCH record would include the name of the index and, for a
SEARCH record, an indication of how the subset of rows visited is
identified. For example:
^(<codeblock>
sqlite> CREATE INDEX i1 ON t1(a);
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SEARCH TABLE t1 USING INDEX i1
</codeblock>)^
<p>
The previous example, SQLite uses index "i1" to optimize
a WHERE clause term of the form (a=?) - in this case "a=1".
The previous example could not use a [covering index], but the following
example can, and that fact is reflected in the output:
^(<codeblock>
sqlite> CREATE INDEX i2 ON t1(a, b);
sqlite> EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?)
</codeblock>)^
|