Documentation Source Text

Check-in [09966391b1]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add additional requirements marks and reword a few sentences in eqp.html.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 09966391b192893e24643a580c473482cd0363db
User & Date: drh 2010-11-15 18:43:30
Context
2010-11-17
01:32
Add the sqlite3_stmt_readonly() function to the change log. check-in: c591c1b79d user: drh tags: trunk
2010-11-15
18:43
Add additional requirements marks and reword a few sentences in eqp.html. check-in: 09966391b1 user: drh tags: trunk
17:35
Minor fixes for sample code in eqp.in. check-in: 897bd4f88e user: dan tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/eqp.in.

    15     15   <p>The [EXPLAIN|EXPLAIN QUERY PLAN] SQL command is used to obtain a high-level
    16     16   description of the strategy or plan that SQLite uses to implement a specific
    17     17   SQL query. Most significantly, it reports on the way in which the query uses
    18     18   database indices. In interpreting and using this information to optimize 
    19     19   database schemas and queries, users might find the documents describing how
    20     20   SQLite [indexing|plans] and [optimizer|optimizes] queries useful.
    21     21   
    22         -<p>An EXPLAIN QUERY PLAN command returns zero or more rows of four columns
    23         -each. The column names are "selectid", "order", "from", "detail". Each
    24         -of the first three column always contains an integer value. The final
    25         -column, "detail", which contains most of the useful information, always
    26         -contains a text value.
           22  +<p>^An EXPLAIN QUERY PLAN command returns zero or more rows of four columns
           23  +each. ^The column names are "selectid", "order", "from", "detail". ^The
           24  +first three columns contain an integer value. ^The final
           25  +column, "detail", contains a text value which carries most of
           26  +the useful information.
    27     27   
    28         -<p>EXPLAIN QUERY PLAN is most useful when used with a SELECT statement, but may
    29         -also be used on other statements that read data from database tables (e.g.
    30         -UPDATE, DELETE, INSERT INTO ... SELECT).
           28  +<p>^(EXPLAIN QUERY PLAN is most useful on a SELECT statement,
           29  +but may also be appear with other statements that read data from database
           30  +tables (e.g. UPDATE, DELETE, INSERT INTO ... SELECT).)^
    31     31   
    32     32   <h2>Table and Index Scans</h2>
    33     33   
    34     34   <p>
    35     35     When processing a SELECT (or other) statement, SQLite may retrieve data from
    36     36     database tables in a variety of ways. It may scan through all the records in
    37     37     a table (a full-table scan), scan a contiguous subset of the records in a
    38     38     table based on the rowid index, scan a contiguous subset of the entries in a
    39     39     database [CREATE TABLE|index], or use a combination of the above strategies
    40     40     in a single scan. The various ways in which SQLite may retrieve data from a
    41     41     table or index are described in detail [strategies|here].
    42     42   
    43     43   <p>
    44         -  For each table the query reads data from, the output of EXPLAIN QUERY 
           44  +  ^For each table read by the query, the output of EXPLAIN QUERY 
    45     45     PLAN includes a record for which the value in the "detail" column begins
    46         -  with either "SCAN" or "SEARCH". "SCAN" is used for a full-table scan,
           46  +  with either "SCAN" or "SEARCH". ^"SCAN" is used for a full-table scan,
    47     47     including cases where SQLite iterates through all records in a table
    48         -  in an order defined by an index. "SEARCH" indicates that only a subset of 
    49         -  the table rows are visited. Each SCAN or SEARCH record includes the
           48  +  in an order defined by an index. ^"SEARCH" indicates that only a subset of 
           49  +  the table rows are visited. ^(Each SCAN or SEARCH record includes the
    50     50     following information:
    51     51   
    52     52   <ul>
    53     53     <li> The name of the table data is read from.
    54     54     <li> Whether or not an index or [automatic indexing|automatic index] is used.
    55     55     <li> Whether or not the [covering index] optimization applies.
    56     56     <li> The selectivity of the subset of records scanned.
    57     57     <li> The estimated number of rows that SQLite expects the scan to visit.
    58         -</ul>
           58  +</ul>)^
    59     59   
    60     60   <p>
    61     61     For example, the following EXPLAIN QUERY PLAN command operates on a SELECT
    62     62     statement that is implemented by performing a full-table scan on table t1:
    63     63   ^(<codeblock>
    64     64       sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    65     65       0|0|0|SCAN TABLE t1 (~100000 rows)
    66     66   </codeblock>)^
    67     67   
    68     68   <p>
    69         -  SQLite estimates that the full-table scan will visit approximately 
           69  +  The example above shows
           70  +  SQLite estimating that the full-table scan will visit approximately 
    70     71     1,000,000 records. If the query were able to use an index, then the 
    71     72     SCAN/SEARCH record would include the name of the index and, for a
    72     73     SEARCH record, an indication of how the subset of rows visited is
    73     74     identified. For example:
    74     75   ^(<codeblock>
    75     76       sqlite&gt; CREATE INDEX i1 ON t1(a);
    76     77       sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1;
    77     78       0|0|0|SEARCH TABLE t1 USING INDEX i1 (a=?) (~10 rows)
    78     79   </codeblock>)^
    79     80   
    80     81   <p>
    81         -  The output above shows that in this case, SQLite uses index "i1" to optimize
    82         -  a WHERE clause filter of the form (a=?) - in this case "a=1". SQLite 
    83         -  estimates that scanning the subset of index entries that match the "a=1"
    84         -  filter means scanning through approximately 10 records. In this case it is
    85         -  not possible to use index i1 as a [covering index], but if it were, the
    86         -  SCAN or SEARCH record would report that as well. For example:
           82  +  The previous example, SQLite uses index "i1" to optimize
           83  +  a WHERE clause term of the form (a=?) - in this case "a=1". SQLite 
           84  +  estimates that about 10 records will match the "a=1" term.
           85  +  The previous example could not use a [covering index], but the following
           86  +  example can, and that fact is reflected in the output:
    87     87   ^(<codeblock>
    88     88       sqlite&gt; CREATE INDEX i2 ON t1(a, b);
    89     89       sqlite&gt; EXPLAIN QUERY PLAN SELECT a, b FROM t1 WHERE a=1; 
    90     90       0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?) (~10 rows)
    91     91   </codeblock>)^
    92     92   
    93     93   <p>
................................................................................
    97     97   ^(<codeblock>
    98     98       sqlite&gt; EXPLAIN QUERY PLAN SELECT t1.*, t2.* FROM t1, t2 WHERE t1.a=1 AND t1.b>2;
    99     99       0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=? AND b>?) (~3 rows)
   100    100       0|1|1|SCAN TABLE t2 (~1000000 rows)
   101    101   </codeblock>)^
   102    102   
   103    103   <p>
   104         -  The second column of output (column "order") indicates the nesting order. In
          104  +  ^The second column of output (column "order") indicates the nesting order. In
   105    105     this case, the scan of table t1 using index i2 is the outer loop (order=0)
   106    106     and the full-table scan of table t2 (order=1) is the inner loop. The third
   107    107     column (column "from"), indicates the position in the FROM clause of the
   108    108     SELECT statement that the table associated with each scan occurs in. In the
   109    109     case above, table t1 occupies the first position in the FROM clause, so the
   110    110     value of column "from" is 0 in the first record. Table t2 is in the
   111    111     second position, so the "from" column for the corresponding SCAN record is
................................................................................
   116    116       sqlite&gt; EXPLAIN QUERY PLAN SELECT t1.*, t2.* FROM t2, t1 WHERE t1.a=1 AND t1.b>2;
   117    117       0|0|1|SEARCH TABLE t1 USING COVERING INDEX i2 (a=? AND b>?) (~3 rows)
   118    118       0|1|0|SCAN TABLE t2 (~1000000 rows)
   119    119   </codeblock>)^
   120    120   
   121    121   <p>
   122    122     In the example above, SQLite estimates that the outer loop scan will visit
   123         -  approximately 3 rows, and the inner loop scan approximately 1,000,000. If
          123  +  approximately 3 rows, and that the inner loop will visit
          124  +  approximately 1,000,000. If
   124    125     you observe that SQLite's estimates are wildly inaccurate (and appear to be
   125    126     causing it to generate sub-optimal query plans), your queries may benefit
   126    127     from running the [ANALYZE] command on the database.
   127    128   
   128    129   <p>
   129    130     If the WHERE clause of a query contains an OR expression, then SQLite might
   130    131     use the [or-connected-terms|"OR by union"] strategy (also described 
................................................................................
   138    139       0|0|0|SEARCH TABLE t1 USING INDEX i3 (b=?) (~10 rows)
   139    140   </codeblock>)^
   140    141   
   141    142   <h2>Temporary Sorting B-Trees</h2>
   142    143   
   143    144   <p>
   144    145     If a SELECT query contains an ORDER BY, GROUP BY or DISTINCT clause, 
   145         -  SQLite may need to use a temporary b-tree structure to perform an 
   146         -  <a href="http://en.wikipedia.org/wiki/Insertion_sort">insertion sort</a> 
   147         -  of the output rows. Or, it may [sorting|use an index]. Using an index is 
   148         -  almost always much more efficient than performing an online insertion sort.
          146  +  SQLite may need to use a temporary b-tree structure to sort the output
          147  +  rows. Or, it might [sorting|use an index]. Using an index is 
          148  +  almost always much more efficient than performing a sort.
   149    149     If a temporary b-tree is required, a record is added to the EXPLAIN
   150    150     QUERY PLAN output with the "detail" field set to a string value of
   151    151     the form "USE TEMP B-TREE FOR xxx", where xxx is one of "ORDER BY",
   152    152     "GROUP BY" or "DISTINCT". For example:
   153    153   
   154    154   ^(<codeblock>
   155    155       sqlite&gt; EXPLAIN QUERY PLAN SELECT c, d FROM t2 ORDER BY c; 
................................................................................
   167    167       0|0|0|SCAN TABLE t2 USING INDEX i4 (~1000000 rows)
   168    168   </codeblock>)^
   169    169   
   170    170   <h2>Subqueries</h2>
   171    171   
   172    172   <p>
   173    173     In all the examples above, the first column (column "selectid") is always
   174         -  set to 0. If a query contains sub-selects, either as part of the FROM
          174  +  set to 0. ^If a query contains sub-selects, either as part of the FROM
   175    175     clause or as part of SQL expressions, then the output of EXPLAIN QUERY
   176         -  PLAN also includes a report for each sub-select. Each sub-select is assigned
   177         -  a distinct, non-zero "selectid" value. The top-level SELECT statement is
          176  +  PLAN also includes a report for each sub-select. ^Each sub-select is assigned
          177  +  a distinct, non-zero "selectid" value. ^The top-level SELECT statement is
   178    178     always assigned the selectid value 0. For example:
   179    179   
   180    180   ^(<codeblock>
   181    181       sqlite&gt; EXPLAIN QUERY PLAN SELECT (SELECT b FROM t1 WHERE a=0), (SELECT a FROM t1 WHERE b=t2.c) FROM t2;
   182    182       0|0|0|SCAN TABLE t2 (~1000000 rows)
   183    183       0|0|0|EXECUTE SCALAR SUBQUERY 1
   184    184       1|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?) (~10 rows)
................................................................................
   196    196     for each row visited by the top level query. Its absence in the record
   197    197     associated with subquery 1 means that the subquery is only run once and
   198    198     the result cached. In other words, subquery 2 may be more performance
   199    199     critical, as it may be run many times whereas subquery 1 is only ever run
   200    200     once.
   201    201   
   202    202   <p>
   203         -  Unless the [flattening optimization] is applied, if a subquery appears in
          203  +  ^(Unless the [flattening optimization] is applied, if a subquery appears in
   204    204     the FROM clause of a SELECT statement, SQLite executes the subquery and
   205    205     stores the results in a temporary table. It then uses the contents of the 
   206         -  temporary table in place of the subquery to execute the parent query. This
          206  +  temporary table in place of the subquery to execute the parent query.)^ This
   207    207     is shown in the output of EXPLAIN QUERY PLAN by substituting a 
   208    208     "SCAN SUBQUERY" record for the "SCAN TABLE" record that normally appears
   209    209     for each element in the FROM clause. For example:
   210    210   
   211    211   ^(<codeblock>
   212    212       sqlite&gt; EXPLAIN QUERY PLAN SELECT count(*) FROM (SELECT max(b) AS x FROM t1 GROUP BY a) GROUP BY x;
   213    213       1|0|0|SCAN TABLE t1 USING COVERING INDEX i2 (~1000000 rows)
................................................................................
   229    229       0|0|0|SEARCH TABLE t2 USING INDEX i4 (c=?) (~10 rows)
   230    230       0|1|1|SCAN TABLE t1 (~1000000 rows)
   231    231   </codeblock>)^
   232    232   
   233    233   <h2>Compound Queries</h2>
   234    234   
   235    235   <p>
   236         -  Each component query of a [compound query] (UNION, UNION ALL, EXCEPT or 
   237         -  INTERSECT) is assigned its own selectid and reported on separately. A
          236  +  ^Each component query of a [compound query] (UNION, UNION ALL, EXCEPT or 
          237  +  INTERSECT) is assigned its own selectid and reported on separately. ^A
   238    238     single record is output for the parent (compound query) identifying the
   239    239     operation, and whether or not a temporary b-tree is used to implement
   240    240     it. For example:
   241    241   
   242    242   ^(<codeblock>
   243    243       sqlite&gt; EXPLAIN QUERY PLAN SELECT a FROM t1 UNION SELECT c FROM t2;
   244    244       1|0|0|SCAN TABLE t1 (~1000000 rows)