<ahref="#Alternative:_Use_comparison"><spanclass="tocnumber">2</span><spanclass="toctext">Alternative: Use comparison</span></a>
</li>
<liclass="toclevel-1 tocsection-3">
<ahref="#Avoid_ORDER_BY"><spanclass="tocnumber">3</span><spanclass="toctext">Avoid ORDER BY</span></a>
<ul>
<liclass="toclevel-2 tocsection-4">
<ahref="#Alternative:_denormalize_the_table"><spanclass="tocnumber">3.1</span><spanclass="toctext">Alternative: denormalize the table</span></a>
</li>
<liclass="toclevel-2 tocsection-5">
<ahref="#Alternative:_multiple_where_clauses"><spanclass="tocnumber">3.2</span><spanclass="toctext">Alternative: multiple where clauses</span></a>
</li>
</ul>
</li>
<liclass="toclevel-1 tocsection-6">
<ahref="#Beware_bulk_INSERTs_into_a_table_with_a_PRIMARY_KEY"><spanclass="tocnumber">4</span><spanclass="toctext">Beware bulk INSERTs into a table with a PRIMARY KEY</span></a>
<ahref="#Get_a_Solid_State_Drive"><spanclass="tocnumber">6</span><spanclass="toctext">Get a Solid State Drive</span></a>
</li>
<liclass="toclevel-1 tocsection-9">
<ahref="#Use_an_INDEX_for_your_SELECTs.2C_especially_JOINs"><spanclass="tocnumber">7</span><spanclass="toctext">Use an INDEX for your SELECTs, especially JOINs</span></a>
</li>
<liclass="toclevel-1 tocsection-10">
<ahref="#Use_TRANSACTIONs_for_multiple_INSERT_.2F_UPDATE_.2F_DELETE"><spanclass="tocnumber">8</span><spanclass="toctext">Use TRANSACTIONs for multiple INSERT / UPDATE / DELETE</span></a>
Like is not performant, as it will search both lowercase and uppercase. You can get around this with PRAGMA case_sensitive_like=OFF;
</li>
<li>
Like does not use an index.
</li>
</ul>
<p>
Consider the following table:
</p>
<pre>
CREATE TABLE tbl1
( id integer NOT NULL PRIMARY KEY
, name varchar(255) NOT NULL
);
CREATE INDEX tbl1__name ON tbl1 (name);
</pre>
<p>
Now, consider the following query:
</p>
<pre>
SELECT id
FROM tbl1
WHERE name LIKE 'a%';
</pre>
<p>
The clause <code>name LIKE 'a%'</code> does not use the index <code>tbl1__name</code>.
</p>
<h3>
<spanclass="mw-headline"id="Alternative:_Use_comparison">= Alternative: Use comparison</span>
</h3>
<p>
If the like has a wildcard at the end, and the data is standardized to one case (all lowercase or all uppercase), use an equality instead:
</p>
<pre>
SELECT id
FROM tbl1
WHERE name >= 'a' AND name < 'b';
</pre>
<p>
This uses the index <code>tbl1__name</code> and returns the same data.
</p>
<h3>
<spanclass="mw-headline"id="Avoid_ORDER_BY">Avoid ORDER BY</span>
</h3>
<p>
ORDER BY will do an expensive sort operation which may not use an index. This will come into play with multiple-table joins
</p>
<pre>
SELECT t1.id
FROM tbl1 t1
JOIN tbl2 t2 ON t1.id = t2.id
ORDER BY t2.age
;
</pre>
<p>
In most cases, SQLite will only apply one index. In this example, it will be the index for the JOIN. No index gets applied for the score column, even if one is available In some cases, SQLite will actually sort the result-set by the ORDER BY first, before it applies the WHERE.
</p>
<h4>
<spanclass="mw-headline"id="Alternative:_denormalize_the_table">Alternative: denormalize the table</span>
</h4>
<p>
Putting all the columns in one table and building an index across them.
</p>
<h4>
<spanclass="mw-headline"id="Alternative:_multiple_where_clauses">Alternative: multiple where clauses</span>
</h4>
<pre>
SELECT t1.id
FROM tbl1 t1
JOIN tbl2 t2 ON t1.id = t2.id
WHERE t2.age > 100 AND t2.age <= 130
;
SELECT t1.id
FROM tbl1 t1
JOIN tbl2 t2 ON t1.id = t2.id
WHERE t2.age > 70 AND t2.age <= 100
;
</pre>
<h3>
<spanclass="mw-headline"id="Beware_bulk_INSERTs_into_a_table_with_a_PRIMARY_KEY">Beware bulk INSERTs into a table with a PRIMARY KEY</span>
</h3>
<pre>
INSERT INTO
INSERT INTO tbl2 (id, key)
SELECT t1.id
FROM tbl1 t1
JOIN tbl2 t2 ON t1.id = t2.id
WHERE t2.age > 100 AND t2.age <= 130
;
</pre>
<p>
Instead, insert into the table with an ORDER BY
</p>
<h3>
<spanclass="mw-headline"id="ATTACH">ATTACH</span>
</h3>
<p>
ATTACH database does not affect performance. There is no difference between the following
</p>
<pre>
SELECT t1.id
FROM tbl1 t1
JOIN tbl2 t2 ON t1.id = t2.id
;
</pre>
<pre>
ATTACH 'db2.sqlite3' AS 'db2';
SELECT t1.id
FROM tbl1 t1
JOIN db2.tbl2 t2 ON t1.id = t2.id
;
</pre>
<h2>
<spanclass="mw-headline"id="Get_a_Solid_State_Drive">Get a Solid State Drive</span>
</h2>
<p>
SQLite does a lot of disk reading and writing
</p>
<h2>
<spanclass="mw-headline"id="Use_an_INDEX_for_your_SELECTs.2C_especially_JOINs">Use an INDEX for your SELECTs, especially JOINs</span>
</h2>
<h2>
<spanclass="mw-headline"id="Use_TRANSACTIONs_for_multiple_INSERT_.2F_UPDATE_.2F_DELETE">Use TRANSACTIONs for multiple INSERT / UPDATE / DELETE</span>
<li><ahref="http://dumps.wikimedia.org/backup-index.html"title="Get wiki datababase dumps directly from Wikimedia">Wikimedia dumps</a></li>
<li><ahref="https://archive.org/search.php?query=xowa"title="Search archive.org for XOWA files">XOWA @ archive.org</a></li>
<li><ahref="http://en.wikipedia.org"title="Visit Wikipedia (and compare to XOWA!)">English Wikipedia</a></li>
</ul>
</div>
</div>
<divclass="portal"id='xowa-portal-donate'>
<h3>Donate</h3>
<divclass="body">
<ul>
<li><ahref="https://archive.org/donate/index.php"title="Support archive.org!">archive.org</a></li><!-- listed first due to recent fire damages: http://blog.archive.org/2013/11/06/scanning-center-fire-please-help-rebuild/ -->
