Android 資料庫優化
本文為效能優化的第一篇——資料庫效能優化,原理適用於大部分資料庫包括Sqlite、Mysql、Oracle、Sql server,詳細介紹了索引(優缺點、分類、場景、規則)和事務,最後介紹了部分單獨針對Sqlite的優化。
1、索引
簡單的說,索引就像書本的目錄,目錄可以快速找到所在頁數,資料庫中索引可以幫助快速找到資料,而不用全表掃描,合適的索引可以大大提高資料庫查詢的效率。
(1). 優點
大大加快了資料庫檢索的速度,包括對單表查詢、連表查詢、分組查詢、排序查詢。經常是一到兩個數量級的效能提升,且隨著資料數量級增長。
(2). 缺點
索引的建立和維護存在消耗,索引會佔用物理空間,且隨著資料量的增加而增加。
在對資料庫進行增刪改時需要維護索引,所以會對增刪改的效能存在影響。
(3). 分類
a. 直接建立索引和間接建立索引
直接建立: 使用sql語句建立,Android中可以在SQLiteOpenHelper的onCreate或是onUpgrade中直接excuSql建立語句,語句如:
- CREATE INDEX mycolumn_index ON mytable (myclumn)
b. 普通索引和唯一性索引
普通索引:
- CREATE INDEX mycolumn_index ON mytable (myclumn)
- CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)
c. 單個索引和複合索引
單個索引:索引建立語句中僅包含單個欄位,如上面的普通索引和唯一性索引建立示例。
複合索引:又叫組合索引,在索引建立語句中同時包含多個欄位,語句如:
- CREATE INDEX name_index ON username(firstname, lastname)
d. 聚簇索引和非聚簇索引(聚集索引,群集索引)
聚簇索引:物理索引,與基表的物理順序相同,資料值的順序總是按照順序排列,語句為:
- CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH ALLOW_DUP_ROW
非聚簇索引:
- CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)
(4). 使用場景
在上面講到了優缺點,那麼肯定會對何時使用索引既有點明白又有點糊塗吧,那麼下面總結下:
a. 當某欄位資料更新頻率較低,查詢頻率較高,經常有範圍查詢(>, <, =, >=, <=)或order by、group by發生時建議使用索引。並且選擇度越大,建索引越有優勢,這裡選擇度指一個欄位中唯一值的數量/總的數量。
b. 經常同時存取多列,且每列都含有重複值可考慮建立複合索引
(5). 索引使用規則
a. 對於複合索引,把使用最頻繁的列做為前導列(索引中第一個欄位)。如果查詢時前導列不在查詢條件中則該複合索引不會被使用。
如create unique index PK_GRADE_CLASS on student (grade, class)
select * from student where class = 2未使用到索引
select * from dept where grade = 3使用到了索引
b. 避免對索引列進行計算,對where子句列的任何計算如果不能被編譯優化,都會導致查詢時索引失效
select * from student where tochar(grade)=’2′
c. 比較值避免使用NULL
d. 多表查詢時要注意是選擇合適的表做為內表。連線條件要充份考慮帶有索引的表、行數多的表,內外表的選擇可由公式:外層表中的匹配行數*內層表中每一次查詢的次數確定,乘積最小為最佳方案。實際多表操作在被實際執行前,查詢優化器會根據連線條件,列出幾組可能的連線方案並從中找出系統開銷最小的最佳方案。
e. 查詢列與索引列次序一致
f. 用多表連線代替EXISTS子句
g. 把過濾記錄數最多的條件放在最前面
h. 善於使用儲存過程,它使sql變得更加靈活和高效(Sqlite不支援儲存過程::>_<:: )
(6)索引檢驗
建立了索引,對於某條sql語句是否使用到了索引可以通過執行計劃檢視是否用到了索引。
使用事務
使用事務的兩大好處是原子提交和更優效能。
(1) 原子提交
原則提交意味著同一事務內的所有修改要麼都完成要麼都不做,如果某個修改失敗,會自動回滾使得所有修改不生效。
(2) 更優效能
Sqlite預設會為每個插入、更新操作建立一個事務,並且在每次插入、更新後立即提交。
這樣如果連續插入100次資料實際是建立事務->執行語句->提交這個過程被重複執行了100次。如果我們顯示的建立事務->執行100條語句->提交會使得這個建立事務和提交這個過程只做一次,通過這種一次性事務可以使得效能大幅提升。尤其當資料庫位於sd卡時,時間上能節省兩個數量級左右。
Sqlte顯示使用事務,示例程式碼如下:
- public void insertWithOneTransaction() {
- SQLiteDatabase db = sqliteOpenHelper.getWritableDatabase();
- // Begins a transaction
- db.beginTransaction();
- try {
- // your sqls
- for (int i = 0; i < 100; i++) {
- db.insert(yourTableName, null, value);
- }
- // marks the current transaction as successful
- db.setTransactionSuccessful();
- } catch (Exception e) {
- // process it
- e.printStackTrace();
- } finally {
- // end a transaction
- db.endTransaction();
- }
- }
其他優化
(1) 語句的拼接使用StringBuilder代替String
這個就不多說了,簡單的string相加會導致建立多個臨時物件消耗效能。StringBuilder的空間預分配效能好得多。如果你對字串的長度有大致瞭解,如100字元左右,可以直接new StringBuilder(128)指定初始大小,減少空間不夠時的再次分配。
(2) 讀寫表
在寫表時呼叫sqliteOpenHelper..getWritableDatabase(),在讀表時候呼叫sqliteOpenHelper..getReadableDatabase(),getReadableDatabase效能更優。
(3) 查詢時返回更少的結果集及更少的欄位。
查詢時只取需要的欄位和結果集,更多的結果集會消耗更多的時間及記憶體,更多的欄位會導致更多的記憶體消耗。
(4) 少用cursor.getColumnIndex
根據效能調優過程中的觀察cursor.getColumnIndex的時間消耗跟cursor.getInt相差無幾。可以在建表的時候用static變數記住某列的index,直接呼叫相應index而不是每次查詢。
- public static final String HTTP_RESPONSE_TABLE_ID = android.provider.BaseColumns._ID;
- public static final String HTTP_RESPONSE_TABLE_RESPONSE = "response";
- public List<Object> getData() {
- ……
- cursor.getString(cursor.getColumnIndex(HTTP_RESPONSE_TABLE_RESPONSE));
- ……
- }
- 優化為
- public static final String HTTP_RESPONSE_TABLE_ID = android.provider.BaseColumns._ID;
- public static final String HTTP_RESPONSE_TABLE_RESPONSE = "response";
- public static final int HTTP_RESPONSE_TABLE_ID_INDEX = 0;
- public static final int HTTP_RESPONSE_TABLE_URL_INDEX = 1;
- public List<Object> getData() {
- ……
- cursor.getString(HTTP_RESPONSE_TABLE_RESPONSE_INDEX);
- ……
- }
非同步執行緒
Sqlite是常用於嵌入式開發中的關係型資料庫,完全開源。
與Web常用的資料庫Mysql、Oracle db、sql server不同,Sqlite是一個內嵌式的資料庫,資料庫伺服器就在你的程式中,無需網路配置和管理,資料庫伺服器端和客戶端執行在同一程式內,減少了網路訪問的消耗,簡化了資料庫管理。不過Sqlite在併發、資料庫大小、網路方面存在侷限性,並且為表級鎖,所以也沒必要多執行緒操作。
Android中資料不多時表查詢可能耗時不多,不會導致anr,不過大於100ms時同樣會讓使用者感覺到延時和卡頓,可以放線上程中執行,但sqlite在併發方面存在侷限,多執行緒控制較麻煩,這時候可使用單執行緒池,在任務中執行db操作,通過handler返回結果和ui執行緒互動,既不會影響UI執行緒,同時也能防止併發帶來的異常。例項程式碼如下:
- ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
- singleThreadExecutor.execute(new Runnable() {
- @Override
- public void run() {
- // db operetions, u can use handler to send message after
- db.insert(yourTableName, null, value);
- handler.sendEmptyMessage(xx);
- }
- });
相關文章
- 資料庫優化 - SQL優化資料庫優化SQL
- 資料庫優化資料庫優化
- MySQL資料庫優化MySql資料庫優化
- 資料庫優化SQL資料庫優化SQL
- Oracle資料庫優化Oracle資料庫優化
- 資料庫效能優化資料庫優化
- 資料庫優化流程資料庫優化
- 資料庫SQL優化大總結之 百萬級資料庫優化方案資料庫SQL優化
- 資料庫SQL優化大總結之百萬級資料庫優化方案資料庫SQL優化
- 資料庫優化之臨時表優化資料庫優化
- 【效能優化】ORACLE資料庫效能優化概述優化Oracle資料庫
- MYSQL資料庫------SQL優化MySql資料庫優化
- 資料庫效能優化2資料庫優化
- 百萬級資料庫優化資料庫優化
- 資料庫查詢優化資料庫優化
- 如何優化資料庫物件優化資料庫物件
- 資料庫優化建議資料庫優化
- 資料庫的優化需要資料庫優化
- 資料庫及SQL優化資料庫SQL優化
- 資料庫優化小計資料庫優化
- Oracle資料庫效能優化Oracle資料庫優化
- 【資料庫】查詢優化之子連線優化資料庫優化
- 資料庫效能優化之SQL語句優化資料庫優化SQL
- 09.Django-資料庫優化Django資料庫優化
- 資料庫應用優化(一)資料庫優化
- 資料庫結構的優化資料庫優化
- 【資料庫】MySQL查詢優化資料庫MySql優化
- MySQL 資料庫與 SQL 優化MySql資料庫優化
- 【資料庫】優化SQL語言資料庫優化SQL
- 資料庫優化效能解析資料庫優化
- 資料庫的優化和效率資料庫優化
- 資料庫優化的步驟資料庫優化
- ORACLE資料庫效能優化概述Oracle資料庫優化
- 資料庫效能優化總結資料庫優化
- 優化資料庫EXP的效率優化資料庫
- 資料庫效能優化-索引與sql相關優化資料庫優化索引SQL
- 【資料庫優化】面向程式設計師的資料庫訪問效能優化法則資料庫優化程式設計師
- 【ITOO】--SQL資料庫優化:切割、資料庫連線池SQL資料庫優化