Android數據庫優化
瞎扯
其實自己在BAT的某家工作過，另外2家也都面試過，據我工作和麪試的情況感覺各大公司對於客戶端數據庫的使用是比較少的，儘量的情況都是在內存中做，或者文件。比如新浪微博大部分的可持久化數據是基於文件的而不是數據庫不知道是基於什麼考量。
但是之前我工作的部門是根據谷歌的開發理念是做了基於以cursor爲model,以loader，notify爲model和view的雙向關聯機制，同時基於uri設計rest風格的數據訪問，整個這套機制我會在以後的文章中闡述以下， 這裏主要還是寫寫我之前做過的一些數據庫優化的情況。
其實瞎扯內容的核心是想說好像大部分的客戶端開發其實是不重視數據庫的，也沒有遵循android的這一套機制的開發，所以可能使用場景有限。
關於三範式
三範式其實講的是數據的唯一性，不可再fen’chai以及低冗餘，但是在現實中因爲客戶端開發和服務器開發的不同，又或者是因爲性能要求的不同我們在數據庫設計上並不完全是遵循三範式的。
關於客戶端的特殊性
其實數據庫設計上來說肯定是服務器的同學設計的更合理性能更好，但是客戶端也是有其特殊性的，以下是我覺得的幾大特殊情況。
1、數據非持久化
對於客戶端來說數據存在數據庫並不一定是爲了持久化，可能是爲了更好的結構化和使用，那麼就會存在設計上和服務器不一樣的地方，我們可以在下垃操作時將數據清除等操作。
2、更能接受冗餘
客戶端的數據和服務器一比，那簡直就是小巫見大巫，雖然移動設備的性能與服務器的性能相比也是小巫見大巫，但是客戶端的開發上我們依然可以接受冗餘來換取更快的查詢速度。
sqlite簡介
sqlite每個數據庫都是以單個文件的形式存在，這些數據都是以B-Tree的數據結構形式存儲在磁盤上。同時sqlite更改數據的時候默認一條語句就是一個事務，有多少條數據就有多少次磁盤操作。
另外還有一個很重要的就是sqlite的共享鎖和獨享鎖機制，sqlite在可以寫數據庫之前，它必須先讀這個數據庫，看它是否已經存在了.爲了從數據庫文件讀取，第一步是獲得一個數據庫文件的共享鎖。一個“共享”鎖允許多個數據庫聯接在同一時刻從這個數據庫文件中讀取信息。“共享”鎖將不允許其他聯接針對此數據庫進行寫操作。
在修改一個數據庫之前，SQLite首先得擁有一個針對數據庫文件的“Reserved”鎖。Reserved鎖類似於共享鎖，它們都允許其他數據庫連接讀取信息。單個Reserved 鎖能夠與其他進程的多個共享鎖一起協作。然後一個數據庫文件同時只能存在一個Reserved 。因此只能有一個進程在某一時刻嘗試去寫一個數據庫文件。
然後將此鎖提升成一個獨享鎖，一個臨界鎖允許其他所有已經取得共享鎖的進程從數據庫文件中繼續讀取數據。但是它會阻止新的共享鎖的生成。也就說，臨界鎖將會防止因大量連續的讀操作而無法獲得寫入的機會。
所以從sqlite本身的機制看來事務的方式去提交數據，本身是多線程乃至多進程數據安全的，但是android在併發寫的時候還是會爆出數據庫鎖住的異常，我們在開發過程中需要儘量避免。
索引簡介
已經有很多文章說了，肯定說的比我好，這裏附帶一個鏈接：數據庫索引
開發注意事項
基於以上的情況來看，我個人在開發中會分爲以下兩種情況注意性能的優化。
1、數據庫性能上
1.1 批量事務插入，提升數據插入的性能
由於sqlite默認每次插入都是事務，需要對文件進行讀寫，那麼減少事務次數就能簡書磁盤讀寫次數從而獲得性能提升。
1.2 單條sql優於多條sql
實測發現，對於幾十條sql插入當你替換成單條sql時性能有所提升，但是這裏要注意的是，換成單條可讀性較差，同時會出現sql超長的錯誤。
1.3 讀和寫操作是互斥的，寫操作過程中可以休眠讓讀操作進行
由於第一步所說的多數據事務插入，從而會導致插入時間增長那麼也會影響數據展示的速度，所以可以在插入過程中休眠操作，以便給讀操作流出時間展示數據。
1.4 使用索引
適當的索引的好處是讓讀取變快，當然帶來的影響就是數據插入修改的時間增加，因爲還得維護索引的變化。不過對於大部分的讀操作多於寫操作的數據庫來說索引還是十分有必要的。關於如何設計索引，可以參考下面這個文章：
索引優化
1.5 使用聯合索引
過多的索引同時也會減慢讀取的速度，很典型的一個情況就是比如要同時根據省市區縣查詢，又可以根據年月日查詢，如果每個都做索引那麼讀取速度將會顯著降低。
對於這種有層級關係的關鍵字，就可以考慮聯合索引了，比如首先根據省查詢，然後根據省市查詢，層層遞進到省市區縣的查詢方式，就可以使用聯合索引，效果非常好。
1.6 勿使用過多索引
1.7 增加查詢條件
當你只要一條數據時增加limit 1,這樣搜索到了後面的就不會再查詢了，大大的加快了速度
1.8 提前將字段的index映射好
減少getColumnIndex的時間，可以縮短一半的時間
2、數據庫設計上
2.1 通過冗餘換取查詢速度
2.2 減少數據來提升查詢速度
比如下拉操作時，先清除舊數據，再插入新數據保證數據庫中的數據總量小，提升查詢速度。
2.3 避免大數據多表的聯合查詢
和2.1的方式其實是一樣的原理，只是這裏需要特別拿出來說明以下，比如有文件表，還有多媒體文件表，你可以設計成一張文件表，一張多媒體關聯表存放多媒體數據，文件信息還是在文件表中，然後通過外鍵關聯。
但是如果兩個表數據很多，主鍵還不一致同時數據從服務器下來的數序也不一致那麼，兩個表的聯合查詢出來的數據要慢的多，這個時候就可以用冗餘來喚起查詢速度了。