まず、2つの点に注意してください。
-この記事では、特定のSQLクエリを最適化する方法ではなく、作業のアルゴリズムについて説明します。
-記事で説明されているアプローチは「生産的な」ハードウェアには関係ありません。Androidを実行している予算のスマートフォンでデータベースを集中的に使用するアプリケーションのインターフェースの「応答性」をどのように高めたかについて説明します。
アプリケーションについて簡単に
危機にwhatしているものを明確にするために、一言で言えば、アプリケーション自体について言います：それはモバイル取引を整理するためのシステムであり、ほとんどのユーザーは販売代理店（TA）です。商品、倉庫の残高（最後の同期時）を確認し、クライアントに必要な数量を記録します。 つまり TA操作アルゴリズムは次のようになります。
-製品1を見つけます。
-番号を入力してください。
-アイテム2を見つけます。
-番号を入力してください。
...
彼らは非常に迅速にそれを行います:)
検索要件
-製品名で検索します（ロシア語でも英語でも可能です）。
-各クライアントは「独自の」価格表を持つことができます。
-すべての商品と在庫のある商品の両方を見ることができる必要があります。
-すべてのサブカテゴリがネストされている選択したカテゴリの製品のリストをフィルタリングする機能があります。
ソースデータ
私が引用した数字は本物です。そうでなければ、すべてを発明する必要はないでしょう。
顧客数：500
製品の数：5000
各クライアントに個別の価格を割り当てると、価格表の5000 * 500 = 2 500 000行が得られます。
SQLiteは非常に高速であるにもかかわらず、問題を「正面から」解決することはできませんでした。 むしろ、すべてが機能しているが、十分な速度ではないと言われます。
解決策
最初の明白なことは、SQLクエリが動的に生成されることです（不必要な結合と条件が必要でない場合、それを除外するため）。 また、実験中に、フォーム内のテーブルの結合が次のことが判明しました。
select * from Table1, Table2 where Table1.Table2Id = Table2.Id
以下より少し速く動作します：
select * from Table1 join Table2 on Table1.Table2Id = Table2.Id
さて、別の非常に自然な瞬間（私はすぐにそれを考えていませんでしたが）、これは次の形式のクエリです：
select Table1.Id from Table1, Table2 ... TableN where Table1.Table2Id = Table2.Id ...
以下よりもはるかに高速に実行されます。
select Table1.Id, ... TableN.FieldN from Table1, Table2 ... TableN where Table1.Table2Id = Table2.Id ...
つまり 同じ要求ですが、1つのフィールドのみを返すことは、必要なすべてのフィールドを一度に「引き出し」ようとする場合よりもはるかに高速に実行されます。
しかし、残りのデータについてはどうでしょうか？
そして、次のような一連の単純なクエリで残りのデータを取得します。
select * from Table1 where Id = ?
このクエリは非常に高速です Idは主キーです。
合計
主な最適化要因は、データを取得するプロセスをいくつかのクエリに分割することでした。そのうちの1つは識別子のリストを返し、残りのデータはより単純なクエリによって返されます。
前述したように、このアプローチにより、予算のスマートフォンでアプリケーションの速度を大幅に加速することができました。 商品のリストをスクロールするとき（表示される各リスト項目に対して複数の「単純な」クエリが実行されるとき）、スローダウンは目に見えません。