當數據庫中存有大量數據的時候，用Cursor查詢時要注意，有可能引發性能問題。數據庫查詢出來的Cursor都會由一個CursorWindow來進行數據管理，包括內存空間的申請和數據的填充。CursorWindow對Cursor中的內容大小有限制，限制為1024*1024也就是1M，換句話說Cursor中數據的大小不能超過1M，如果超過1M會引發如下的錯誤：
08-23 05:48:31.838: DEBUG/Cursor(1805): skip_rows row 149
08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7
08-23 05:48:31.849: DEBUG/Cursor(1805): finish_program_and_get_row_count row 12
08-23 05:48:31.851: DEBUG/browser/BrowserBookmarkFoldersAdapter(1805): getView()-Position:149
08-23 05:48:32.019: DEBUG/Cursor(1805): skip_rows row 148
這表明CursorWindow中的空閒空間已經不足，已經在申請新的空間，但似乎申請失敗。這個錯誤有時候會導致查詢得到的Cursor為null，有時候不會引發太嚴重的問題。但是它會引起性能上的問題，不停的申請空間會占用大量的CPU時間，從而導致整個手機變卡。特別是在ListView或GridView中綁定的Cursor，會導致無法滑動，或者滑動變的十分的卡。用Android2.3的原生Browser，打開其中的歷史記錄，當有超過200條歷史記錄時，不停的滑動，特別是由下向上滑時會變的十分的卡，而對於其書簽，如果條目超過100，且每個都有縮略圖時，滑動會變得特別的卡，甚至都打不開，就是這個原因。
這個問題沒有根本的解法，這是Android系統的限制，唯一可行的就是想辦法避免，也就是盡可能讓Cursor的大小 小於1M，以下是可行的方法：
1. 只查詢需要的字段
這個特別重要，根據UI顯示的需要，或者實際的需要查詢需要的字段。就是一定要給ContentResolver.query(uri, projection)第二個參數PROJECTION，如果這個參數為null，那麼就會查詢表中所有的字段，那麼當條數一增加Cursor的大小 會增長很快。Browser中歷史記錄的原因就是它在query的時候查詢了所有的字段，其數所庫中保存了favicon和thumbnail二進制文件，因此當包含了這二個字段時，Cursor的容量很容易就達到了限制。
2. 二進制文件不要存在數據庫中
數據庫僅適用於保存一些較短文字，整數，布爾，浮點數等一些，易於查詢和操作的輕量級的數據，目的也是在於快速搜索和查詢。對於像圖片，較長的文字（如文章）等大數據，最好直接以文件形式存儲在硬盤中，然後在數據庫保存它們的訪問路徑。對於像favicon這樣的小圖片也可以考慮存在數據庫中，但是像對於thumbnail的圖片就不明智，除非整個應用在數量上有限制（比如只有幾十或百級）否則很容易在查詢的時候達到1M的限制。
3. 對於特別大量的數據超過5000級或萬級或十萬級或百萬級的要分段查詢
無論表中的一條記錄數據量如何的小，當條數達到5000級或者萬級或者更多的時候，還是會達到1M的限制，這時就需要分段查詢，比如每次查詢500個，或者1000個。另外，如果是要做展示用，這麼多數據一下子出來，用戶也不方便查看。
【實例】Android2.3書簽，歷史記錄和最多訪問三個頁面當數據量達到300左右時，就會出現滑動很卡的現象，特別是由下向上滑動時，特別的卡，會狂打出：
08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7
這樣的LOG。而書簽似乎都沒有辦法打開和滑動，其特別的卡。
究其原因就是它們在查詢的時候都用了同一個字段集Browser.HISTORY_PROJECTION這個是把bookmarks表中的所有字段都 查詢出來。書簽，歷史記錄和最多訪問雖是三個不同的展示頁，但它們的數據是相同的都是來自bookmarks表。Bookmarks表中存有_id,title,url,bookmark,favicon,touch_icon,thumbnail等字段，其中favicon和thumbnail是二進制圖片數據(byte[])。Browser.HISTORY_PROJECTION裡面包含了所有的字段，當然也包含了favicon和thumbnail，所以當條目一旦達到200多時，Cursor就會達到其1M的限制，因此會導致性能下降，滑動變卡。
事實上對於歷史記錄和最多訪問二個頁面來講thumbnail和touch_icon根本就沒有用到，它只需要_id,title,url,bookmark和favicon；對於書簽頁，也僅是在GRID時才用到thumbnail。所以，只需要把查詢時的字段集Browser.HISTORY_PROJECTION中的THUMBNAIL去掉，即可以解決滑動變卡。