Android SQLite數據庫查詢優化方法

數據庫的性能優化行業裏面廣泛偏少，今天這篇但願給你們帶來點幫助

咱們在使用SQLite進行數據存儲查詢的時候，要進行查詢優化，這裏就會用到索引，C端的數據量大部分狀況下面雖然不是很大，但良好的索引創建習慣每每會帶來不錯的查詢性能提高，同時在未知的未來經得住更大數據的考驗，那如何優化數據庫查詢呢，下面咱們用例子一一演示下。

先建個測試表table1,包含了三個索引：

sqlite> .schem
CREATE TABLE table1(id integer primary key not null default 0,a integer,b integer, c integer);
CREATE INDEX a_i on table1 (a);
CREATE INDEX a_i2 on table1 (a,b);
CREATE INDEX a_i3 on table1 (c);

在常見的數據庫系統裏面，進行SQL查詢檢驗都是用explain關鍵字，好比：

sqlite> explain select * from table1;
addr  opcode         p1    p2    p3    p4             p5  comment      
----  -------------  ----  ----  ----  -------------  --  -------------
0     Init           0     10    0                    00  Start at 10  
1     OpenRead       0     2     0     4              00  root=2 iDb=0; table1
2     Rewind         0     9     0                    00               
3       Rowid          0     1     0                    00  r[1]=rowid   
4       Column         0     1     2                    00  r[2]=table1.a
5       Column         0     2     3                    00  r[3]=table1.b
6       Column         0     3     4                    00  r[4]=table1.c
7       ResultRow      1     4     0                    00  output=r[1..4]
8     Next           0     3     0                    01               
9     Halt           0     0     0                    00               
10    Transaction    0     0     4     0              01  usesStmtJournal=0
11    Goto           0     1     0                    00

立馬就會獲得輸出，這些輸出表示SQLite執行這條SQL用到的每句指令，這個其實不怎麼直觀，咱們用到更多的是EXPLAIN QUERY PLAN，以下：

sqlite> explain QUERY PLAN select * from table1;
0|0|0|SCAN TABLE table1

這條SQL語句是查詢了整張表，因此結果關鍵字SCAN表示要完整遍歷，這種效率是最低的，接下來咱們試試加個查詢條件：

sqlite> explain QUERY PLAN select * from table1 where a=1;
0|0|0|SEARCH TABLE table1 USING INDEX a_i2 (a=?)

加上where a=1以後關鍵字變成了SEARCH，表示再也不須要遍歷了，而是使用了索引進行了部分檢索，另外這條輸出還有更多信息，好比使用了索引a_i2，而括號裏面的a=?則表示是這個查詢條件引發的

咱們稍微修改下SQL：

sqlite> explain QUERY PLAN select a from table1 where a=1;
0|0|0|SEARCH TABLE table1 USING COVERING INDEX a_i (a=?)

把select 變成了select a，發現explain輸出有細微變化，從INDEX變成了COVERING INDEX，CONVERING INDEX表示直接使用索引查詢就能夠獲得結果，不須要再次回查數據表，這樣效率更高。而以前的查詢由於是使用，索引裏面只有a記錄，因此必需要查詢原始記錄才能獲得b，c字段。咱們再試下這條SQL：

sqlite> explain QUERY PLAN select a,b from table1 where a=1 and b=1;
0|0|0|SEARCH TABLE table1 USING COVERING INDEX a_i2 (a=? AND b=?)

贊成由於索引a_i2已經包含a和b了，因此也是使用CONVERING INDEX。那有同窗可能會問了，那咱們建索引的時候都把其餘字段都加進去唄，雖然查詢用不到，但不用二次查詢原始記錄效率高。理論上這樣是可行的，但這裏有個重要問題就是數據冗餘太嚴重了，致使索引和原始數據同樣大，在海量數據存儲的數據庫裏面磁盤消耗是個問題，因此如何選擇可能要作個平衡。

接下來咱們把and換成or：

sqlite> explain QUERY PLAN select a,b from table1 where a=1 or b=1;
0|0|0|SCAN TABLE table1 USING COVERING INDEX a_i2

發現又變回SCAN了，但仍然使用到了索引a_i2，對比下這條SQL：

sqlite> explain QUERY PLAN select a,b from table1 where a=1;
0|0|0|SEARCH TABLE table1 USING COVERING INDEX a_i2 (a=?)

多了個查詢條件b=1以後效率變差了，這是爲何呢？這裏要引出咱們建立索引使用的最關鍵的原則：前綴索引。

索引通常是使用B樹，前綴索引簡單來說，就是要想能使用這個索引，查詢條件必須知足索引創建涉及到的字段，而且和查詢使用的順序一致。

咱們回頭看剛纔那個or的例子，對於查詢條件a=1，他能使用a_i2(a,b)這個索引，由於索引順序也是a開頭的。但or的例子裏面還或上一個查詢條件b=1，對於這個查詢就沒有索引能夠用了，由於沒有b開頭的索引存在。a_i2(a,b)這個索引裏面雖然有b，但b對於b=1這個查詢條件來講不是在前面，不知足前綴索引原則。

而對於剛纔那個and的例子，則可以徹底使用索引，由於存在索引a_i2(a,b)，能夠想象成先按索引a過濾數據，剩下數據再用索引b過濾數據。對於and條件來講，索引裏面字段的順序換一下也是沒有關係的，數據庫會自動優化選擇，好比：

sqlite> .schem
CREATE INDEX a_i22 on table2 (b,a);
sqlite> explain QUERY PLAN select a,b from table2 where a=1 and b=1;
0|0|0|SEARCH TABLE table2 USING COVERING INDEX a_i22 (b=? AND a=?)

若是or查詢也要充分使用索引，聰明的讀者必定想到了，那就是要建2個索引，以下：

CREATE TABLE table3(id integer primary key not null default 0,a integer,b integer, c integer);
CREATE INDEX a_i222 on table3(a);
CREATE INDEX a_i2222 on table3(b);
sqlite> explain QUERY PLAN select a,b from table3 where a=1 or b=1;
0|0|0|SEARCH TABLE table3 USING INDEX a_i222 (a=?)
0|0|0|SEARCH TABLE table3 USING INDEX a_i2222 (b=?)

咱們再來看一個進階的，加上一個排序：

CREATE TABLE table1(id integer primary key not null default 0,a integer,b integer, c integer);
CREATE INDEX a_i2 on table1 (a,b);

sqlite> explain QUERY PLAN select a,b from table1 where a=1 order by b;
0|0|0|SEARCH TABLE table1 USING COVERING INDEX a_i2 (a=?)


CREATE TABLE table3(id integer primary key not null default 0,a integer,b integer, c integer);
CREATE INDEX a_i222 on table3(a);
CREATE INDEX a_i2222 on table3(b);

sqlite> explain QUERY PLAN select a,b from table3 where a=1 order by b;
0|0|0|SEARCH TABLE table3 USING INDEX a_i222 (a=?)
0|0|0|USE TEMP B-TREE FOR ORDER BY

對比這2個查詢，發現下面這個多了個USE TEMP B-TREE FOR ORDER BY。對於第一個查詢來講，咱們能夠看到排序也是一樣知足前綴索引原則（先按索引a過濾數據，剩下數據用索引b排序）。對於第二個查詢來講，由於不知足這個原則致使多了個臨時表來作排序。看到這裏你們應該理解前綴索引的意思了。

咱們再看這個樣子，把查詢條件和排序換下：

sqlite> explain QUERY PLAN select a,b from table1 where b=1 order by a;
0|0|0|SCAN TABLE table1 USING COVERING INDEX a_i2

顯然不知足前綴索引原則了，由於須要先按索引b過濾數據，但b不是第一個。

常規的查詢語句大部分是and，or，order的組合使用，只須要掌握上面說的原則，必定能寫出高性能的數據庫查詢語句來。

而對於更高級的一些連表能夠繼續翻閱官方文檔：

https://www.sqlite.org/eqp.html

https://www.sqlite.org/lang_e...