Android変数SQLiteクエリのパフォーマンスを選択する - 説明がありますか？

Question

私はSQLiteデータベースを持っています。これは読み取り専用のデータベースです。アプリの構築とデプロイ後に更新や変更はありません。私は州のフィールドにインデックスを持っています。私のアプリケーションは、単純なselectステートメントを使用して、指定された状態に一致するすべての行を取得します。私は説明を使用して、クエリ・プラン・ステートメントを説明し、クエリがインデックスを使用していることを確認しました。

ほとんどの場合、クエリは2番目に戻ってきます。偉大ではありませんが、アプリケーションにとって十分です。

頻繁にクエリが長くなります（最大14秒、しばしば3〜4秒）。正確に同じバイナリによって呼び出される同一の電話機上の正確に同じ読み取り専用データベース（およびテーブル）上の正確な同じクエリ。

私は、ガベージコレクションが発生していない、とは例外が生じることがあるだけでばらつきがありlogcat

を監視から生成されていないことを見ることができます。一貫性のないユーザーエクスペリエンスをもたらすバリエーション。

SQLiteデータベースシステムは、電子メールクライアントなどの他のアプリケーションと共有されているようです。私のクエリが別のアプリケーションのクエリの後ろにキューイングされている可能性があります。そのため、共有SQLiteデータベースシステムが実際にクエリを実行するときにバリエーションが発生しますか？この場合、「自分のSQLiteインスタンスを作成する」ことができますので、一貫したパフォーマンスを得ることができますか？

共有されたSQLiteデータベースシステムではない（と私は自分自身のインスタンスを持っている）場合は、他のすべてが同等であれば、クエリのパフォーマンスにこのような大きな変化が生じている可能性がありますか？

行がかなり長く（単にアドレスよりも多くの情報を持っている）、私のコードの他の多くの部分が使用されているので、データをメモリに持ち込んでそこでクエリを実行することは簡単ではありませんより複雑な選択クエリを使用できます。私は、パフォーマンスのばらつきを、この質問のために単に最も単純な「where where state =」クエリーに絞り込んだ（助けを求める）。

Answer 1

SQLiteデータベースシステムは、電子メールクライアントなどの他のアプリケーションによって共有されているようです。

正確ではありません。 ストレージは他のアプリで共有しています。 Android 1.xやほとんどの2.xデバイスでは、内部ストレージはYAFFS2形式になっています.YAFFS2は、一度に1つのプロセスがストレージにアクセスできるようにします。これは、YAFFS2の代わりにext4を実行しているAndroid 3.0以降のデバイス（および一部の2.3デバイス）では問題になりません。

私のクエリが別のアプリケーションのクエリの後ろにキューイングされている可能性があります。そのため、共有SQLiteデータベースシステムが実際にクエリを実行したときのバリエーションがありますか？

正確ではありません。あなたのディスクI/Oは、別のアプリのディスクI/Oの後ろに並んでいる可能性があります。