Force.com クエリオプティマイザー FAQ

Q: Oracle のビルトインの代わりに、Salesforce は独自の SQL 最適化のロジックを持っていますか？

A: Force.com はマルチテナントのプラットフォームです。マルチテナントの統計を考慮するため、プラットフォームは特定のテナントの要求を満たす最適な SQL を決定し、独自の SOQL クエリオプティマイザーを持っています。

Q: どのくらいの頻度でクエリオプティマイザーが使用する統計情報が生成されていますか？

A: 統計は毎週収集されています。統計が計算されない場合、オプティマイザーは動的な事前クエリを実行し、その結果は 1 時間キャッシュされます。

Q: パフォーマンステストを実施しているときにキャッシュをクリアする方法はありますか、結果はキャッシュの偏りではないですか？

A: 残念ながら、ありません。しかしながら、選択制の高いフィルタ条件を持つクエリは、キャッシュによるパフォーマンスの変動が少なく、より安定して動作します。

アーカイブ

Q: Salesforce はアーカイブオプションを提供していますか？

A: 大量な組織データのアーカイブのために最適なオプションは Force.com Bulk API です。AppExchange で多くのサードパーティーのツールを含む、多くのツールがこの API のために UI を提供します。

Q: どのようなアーカイブ戦略が使用されるべきですか？

A: アーカイブ戦略は、多くの場合、時間ベースです。例えば、6 カ月以上前にクローズされたすべての商談をアーカイブします。Force.com Bulk API を使用しこのデータをクエリして外部のシステムへコピーし、アーカイブしたレコードを削除するために BulkAPI を使用することができます。

ツール

Q: 将来のリリースではクエリのテストを容易にするために、開発者コンソールとは別のツールが用意されますか？その場合、クエリのパフォーマンスを向上させるアドバイスができるようになるのでしょうか？

A: (セーフハーバー) 弊社はお客様がクエリのパフォーマンスをプロファイリングするのに役立つ機能強化を検討していますが、パフォーマンスを向上させるための方法を提案することは、コンピュータサイエンスにおいて非常に難しい問題であることに留意してください。すなわち、クエリのパフォーマンスが悪いことを示すことは簡単ですが、書き換えることは困難です。

SOQL

Q: SFDC は、ANSI 標準 SQL を使用するように変更することができますか？

A: Force.com のクエリ言語である SOQL は ANSI 標準 SQL ではありません。しかしながら、多くの点で類似しており、ほとんどの SQL 開発者にとって学ぶことは簡単なはずです。どうしても Force.com で SQL を使用しなければいけない場合は、Progress Data Direct のようなサードパーティーのデータアクセスドライバ（ODBC および JDBC）を検討してください。

Q: Salesforce がしきい値でバイアスされるのはなぜですか？私は若干のオーバーヘッドが存在していることを把握しています。しかし、ほとんどのお客様は標準インデックスではなく、カスタムインデックスに興味を持っています。

A: 標準インデックスとカスタムインデックスのしきい値の違いは、データベースアーキテクチャ、および、弊社のマルチテナントモデルによって決められます。

Q: クエリがしきい値に達した場合はどうなりますか？

A: オプティマイザーが与えられたフィルタ条件は、インデックスに対応する選択的しきい値を超えたと判断した場合に、インデックスを使用するオーバーヘッドが最適ではないため、オプティマイザーはインデックスを使用しません。

Q: インデックス項目に null 値がある場合、インデックスは使用されますか？

A: フィルタ条件が明確に null を検索し、インデックスが null をサポートしている場合、オプティマイザーはインデックスを考慮します。インデックス内の null の数が下記の選択的しきい値を下回った場合は、インデックスを使用することができます。Winter '13 から、Salesforce のカスタマサポートに依頼することで、null 行を含むカスタムインデックスを作成することができるようになりました。全ての標準インデックスは自動的に null を含みます。

Q: "without sharing" クラスを持っているとき、レコードの可視性はどうなりますか？完全なデータベースを検索しますか？

A: クエリの実行プランを決定するとき、オプティマイザーはレコードの可視性を考慮します。共有ルールがクエリを実行するユーザためにデータの可視性を制限しない場合、オプティマイザーはレコードの選択のための他のアプローチ(indexes、skinny tables など)のみを検討します。

Q: システム管理者のクエリは他のプロファイルよりも高速に処理されますか？

A: すべてのデータを閲覧できるプロファイルは共有評価がなく、かつ SQL の実行が限定されたデータしか閲覧できないプロファイルと比較して異なっています。選択性に応じて、弊社は、もっとも効率的な方の共有または選択フィルタを判断します。

Q: IN() 句内でいくつの値を持つことができるかの制限はありますか？

A: IN 句内の値の数に制限はありません。唯一の制限は、SOQL クエリの最大サイズ（Spring '13 では 10,000 文字、Summer '13 では 20,000 文字）を実行できないことです。

Q: クロスオブジェクト数式項目はパフォーマンスへの影響はありますか？

A: ある程度の影響の可能性があります: 弊社は下記の Wiki 記事（英語）によって詳細に説明されている数式のためにインデックスをサポートしません。
http://blogs.developerforce.com/engineering/2013/02/force-com-soql-best-practices-nulls-and-formula-fields.html

数式はより複雑な SQL に展開されます。そして、それらの複雑さに基づいて、SQL クエリの制限の例外を発生させます。インデックスを付けられないとき、それらは一般的にフィルタリングされるのが遅くなります。

Q: 読み取り専用で Visualforce ページに1M 行を表示する必要がある場合、本記事のシナリオの対象となりますか？

A: controller / extension クラス内ではそうです。表示されるレコードを取得するあらゆる SOQL は、この記事で論じられている問題の対象です。レコードをページにレンダリングする際のパフォーマンスは、Visualforce ページのマークアップに依存します。

Q: UI で SOQLクエリをチェックするツールはありますか？
A: はい、クエリプランツールで SOQL クエリを確認することができます。
https://help.salesforce.com/articleView?id=000199003&type=1

SOSL

Q: SOSL はどのような意味ですか？

A: SOSL は Salesforce Object Search Language の略です。それは、ひとつ以上のオブジェクトにまたがるテキストを検索するために用いる検索言語です。その言語は、Apache Lucene で使用する検索言語とよく似ています。より詳細については、次のリンクを参照してください（英語）。
https://developer.salesforce.com/docs/atlas.ja-jp.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_sosl_intro.htm

Q: SOSL よりも SOQL の方が好ましいですか？

A: SOQL は Force.com のデータベースクエリ言語です。SQL に似ています。SOQL は Force.com のフルテキスト検索言語です。200 以下のレコードを取得する必要があり、OR 句を使用しテキスト項目を検索している場合、SOSL が使用されるべきです。なお、Summer '13 では、SOSL で 2000 レコードまで取得します。それぞれの言語の詳細について、次のクイックリンクを参照してください。
https://developer.salesforce.com/docs/atlas.ja-jp.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_sosl_intro.htm

Q: SOSL が SOQLよりもパフォーマンスがよいかどうかを、いつ判断するべきですか？

A: 一般的にいえば、 SOSL はこれらのシナリオにおいて最適です。

複数のオブジェクト、インデックス付けされていないテキスト指向の項目に渡って検索している。
「あいまいな」テキストマッチングを必要とするとき。
中国語、日本語、および、韓国語（CJK）のサポートを必要としているとき。

インデックス付き/インデックスに登録可能な項目

Q: 標準インデックスの恩恵を得るための要件は何ですか？どの項目が標準インデックスに含まれますか？

A: インデックスが付けられた標準項目: Id、Name、OwnerId、CreateDate、SystemModstamp は、標準およびカスタムオブジェクトの両方でインデックスが作成されます。

RecordType (その機能を持つすべての標準オブジェクトでインデックスが付けられます)
主従関係項目 (標準項目のみ)
ルックアップ項目 (標準項目のみ)

フィルタ条件でこのような項目を使用する場合、オプティマイザーはインデックスの使用を考慮します。

Q: Salesforce によってカスタムインデックスはいつ考慮されますか？

A: クエリの実行時にインデックスの存在は、弊社のクエリオプティマイザーによってチェックされます。この項目を使用するフィルタが選択的であるときだけ、カスタムインデックス項目はパフォーマンスを向上させます。特定のクエリに対する支援が必要であれば、問い合わせ (開発者サポート) を起票して Salesforce サポートへお問い合わせください。

Q: どの項目がインデックスであるかを知る方法はありますか？

A: 次の記事、"Database Query & Search Optimization Cheat Sheet" を確認してください（英語）。

現在、UI の設定はカスタムインデックスを表示しません。しかし、弊社はインデックスを持つ項目が表示されるように近い将来、ユーザインターフェイスを向上させるために取り組んでいます（セーフハーバー）。

Q: 外部 ID は標準、または、カスタムインデックですか？

A: 外部 ID としてマークされている項目は常にカスタムインデックスです。

Q: ユニーク項目は自動的にインデックスが付きますか？

A: はい。ユニーク、外部 ID、外部キーはいつでも可能なときに自動的にインデックス付けされます。

Q: 日付/時間項目を「インデックスに登録可能」にする計画はありますか？

A: Salesforce サポートへ特定の日付/時間項目のインデックス化をリクエストすることができます。

Q: 取引先責任者のメール、および、電話番号項目はインデックス付けされていますか、または、要求されたときだけインデックス付けされますか？

A: 取引先責任者メール項目は標準インデックスです。しかし、電話番号項目はデフォルトではインデックス付けされません。

Q: カスタムインデックスの数に制限はありますか？

A: はい。プラットフォームはオブジェクトごとに限られた数のインデックスをサポートします。一般的に言えば、クエリの動作を促進する場合のみ、カスタムインデックスを導入することが最良の方法ですが、あまり多くのカスタムインデックスを導入すると、DML 操作（INSERT、UPDATE、DELETE）、および、バルクデータロードの動作が低下します。

Q: カスタムインデックスはパッケージにすることができますか？

A: 外部 ID としてマークされた項目へ関連付けされたカスタムインデックスはパッケージにすることができます。

Q: インデックスはアプリケーションをインストールするお客様にロールオーバーされますか？AppExchange アプリケーションを作成して、カスタマサポートにインデックスの作成を依頼するとします。インデックスはお客様の組織で保持できますか？

A: http://blogs.developerforce.com/engineering/2013/02/force-com-batch-apex-and-large-data-volumes.html を参照してください。

インデックス付き項目の作成

Q: 外部 ID ではないカスタム項目にどのようにしてインデックスを付けますか？どのようにカスタムインデックスを作成しますか？

A: 選択リスト、チェックボックス、および、数式項目にカスタムインデックスを作成するためには、Salesforce サポートへお問い合わせいただく必要があります。外部 ID として、それらをマークすることにより、テキスト項目へカスタムインデックスを追加することができます。

Q: オブジェクト項目が作成された際に UI 上のオプションとして、インデックスを作成する機能を追加する計画はありますか？

A: 現在、そののような方法でカスタムインデックスの作成できるようにする計画はありません。オーバーヘッドに留意し、必要なインデックスのみを持つことができます。インデックスを追加し、それらを評価し、それらを削除することは理想的ではありません。それゆえに、弊社は作成の前に最初にカスタムインデックスの影響を分析したいと考えています。

Q: 組織のクエリで傾向を見つけた場合、インデックス、または、スキニーテーブルの作成のようなものを自動化する計画はありますか？

A: 内部的には、オプティマイザーはカスタムインデックスの候補を追跡します。また、自動的に選択性が高いと判断される一列のインデックスを作成します。スキニーテーブルは Salesforce サポートの分析によってのみ作成されます。このブログ（英語）はスキニーテーブルを作成する前に必要とする考慮事項について投稿しています: http://blogs.developerforce.com/engineering/2013/03/long-and-short-term-approaches-for-tuning-force-com-performance.html

Q: 問い合わせを起票してから項目をインデックス化するためのサポートにどのくらいの時間がかかりますか？

A: Salesforce サポートは、ケースバイケースで各シナリオを検討します。場合によっては、フィルタに使用している項目が選択的ではなく、クエリのパフォーマンスを向上できないことがあります。そのような場合には、他のアプローチについて検討することを提案します。

Q: 外部 ID として項目をマークした後に、インデックス作成にどのくらいの時間がかかりますか？

A: 一度、外部 ID として項目をマークすると、Force.com はインデックスの作成をキューイングします。インデックスを作成するための時間は、どれくらいのデータが既にオブジェクトに存在するかによります。オブジェクトが空の場合、インデックスはとても速く作成されます。オブジェクトが数百万件のレコードを持っている場合、バックグラウンドでインデックスが作成されるまでに数分かかる可能性があります。

SOQL クエリの最適化

一般的なシナリオ

Q: 大きなデータセットのために For ループの中で直接 SOQL を使用する効果はありますか？

A: For ループ SOQL を使用することは For ループ内のコードを 200 レコードごとに一回実行されます。しかし、それは実際にはクエリのパフォーマンスを向上させることはありません。

Q: 特定の date/datetimes へ日付リテラルを変更することはパフォーマンスを向上させますか？

A: それは、パフォーマンスの向上になりません。

Q: ネストしたクエリを使用することは良い実践ですか？

A: パフォーマンスを向上させるため、SOQL 内でネストしたクエリも、その他の SOQL と同じルールに直面します。選択的なフィルタを追加すること、取得するレコードの数を制限すること、そして、冗長なオブジェクトへの接点を取り除くことはパフォーマンスの向上に役立ちます。ネストされたクエリを使用するかは、ユースケースから判断するべきです。

Q: NOT IN は最適化されるときに、IN と同様に動作しますか？

A: オプティマイザーは、"field NOT IN (value, value, value)" を "field != value AND field != value AND field != value" として判断します。現在、!= null と != ブール値のみを最適化することができます。

Q: クエリオプティマイザーがインデックスを使用するように、"not in" SOQL クエリを記述する最善の方法は何ですか？

A: いくつかのアイデアがあります:

1) 数値が存在し、それらの和が選択的である場合、IN 演算子へ切り替えます
2) その他の選択的フィルタをクエリに追加します

Q: IN 句において、32 の可能な値から 30 を持つとしましょう。IN 句内の全てを持つことは not equal to を使用することよりも良いですか？

A: このシナリオにおいては、field != value1 and field != value2 は最適化することができません。しかしながら、field IN (value1, value2, …, value30) の結果が選択的である場合（下記のしきい値）、インデックスは考慮されるでしょう。

Q: LIMIT なしで ORDER BY Id DESC はクエリを選択的にしますか？

A: ORDER BY 句は選択性とは関係がありません。選択性は利用可能なフィルタ条件（WHERE 句）とレコードの可視性（共有ルールなど）によって決定されます。オプティマイザーがどの行を返すかを一旦、決定したら、それはリターンセット内のレコードをソートするための ORDER BY ロジックを適用します。

Q: 私たちのパフォーマンスの問題を持つ重要な SOQL 文に "ORDER BY Name" 文が含まれています。恐らく、これを取り除くべきでしょう。これは良いですか、悪いですか？また、それは多くの影響を与えませんか？

A: LIMIT を伴わない ORDER BY 句は最適化されません。しかしながら、インデックス項目（標準、または、カスタム）の ORDER BY + LIMIT は実際にはとても役に立つ最適化でしょう。（例えば、潜在的に大きい（1000+、レコードの一覧）最初の 10 行を表示するページなど。）

Q: 動的 SOQL についてはどうですか？検索された同じ項目を持つ、WHERE 句の、しかし、WHERE 句で異なるルックアップ値の動的 SELECT の繰り返しの呼び出される最適化はありますか？

A: 最適化は、呼び出しごとに提供されるそれぞれの値に基づいて決定されます。

Q: ディビジョンはどのように役立ちますか？フィルタ上のディビジョンを含むベストプラックティスは何ですか？

A: ディビジョンは、物理的にパーティションデータを使用することができる機能です。パーティションキー（どのディビジョンにレコードを置くか決定する項目）に基づいてデータを照会するときにディビジョンは理にかなっています。より詳細な情報については、ディビジョンを使用してデータを整理するを参照してください。

特定のシナリオ

Q: 選択性をテストするために従うべきアプローチはなんですか？

A: 分析のサンプルをここで閲覧することができます（英語）: http://www.salesforce.com/us/developer/docs/apexcode/Content/langCon_apex_SOQL_VLSQ.htm

Q: バッチプロセスでオブジェクトからインデックス化された項目を介し1,000,000 レコードを照会したいです。7,000,000 レコードでは動作しました。しかし、10,000,000 レコード以上のオブジェクトの場合はタイムアウトし、バッチが動作しませんでした。どうしたらよいですか？

A: 大量のデータおよびバッチ Apex については、次のブログを参照してください（英語）。https://developer.salesforce.com/blogs/engineering/2013/02/force-com-batch-apex-and-large-data-volumes.html

Q: 返却されるレコードの数に関係なく、初回の実行で 40 秒かかるクエリ（複数のサブクエリ含む）があります。それ以降のクエリは高速です。これはクエリのコンパイル時間に依存した最適化できない事象ですか？クエリをシンプルに書き直し、別々のトランザクションにサブクエリを取り出す方がよいでしょうか？

A: ほとんどの行がデータベースのキャッシュに格納された場合、取り込み時間が大幅に減少するため、実行時間は一様ではありません。サブクエリが大きなオブジェクトを結合する場合、そのクエリを複数のトランザクションに分割する方がよいかもしれません。さらに、クエリカーソルロケータは、サブクエリが使用されるときに考慮されるべきものです。

Q: 下記のようなクエリをどのように最適化することができますか？

SELECT id, Email, Phone, MobilePhone, HomePhone, OtherPhone, Owner.profile.name, Account.IsPersonAccount

FROM Contact

WHERE

Email IN :emails

OR Phone IN :phones

OR MobilePhone IN :phones

OR HomePhone IN :phones

OR OtherPhone IN :phones

A: 上記のクエリがしきい値内にある場合 (レコードの 10% よりも少ないレコードを返す OR 句)、そのクエリは最適化されます。しかし、取引先責任者レコードのほとんどを返す場合、それは最適化されず、SOSL が代わりに考慮されるべきです。

スキニーテーブル

Q: スキニーテーブルとは何ですか？

A: スキニーテーブルは、標準またはカスタムベースの Salesforce オブジェクトから項目のサブセットが含まれている Force.com プファットフォームでのカスタムテーブルです。詳細については次の記事を参照してください（英語）。http://blogs.developerforce.com/engineering/2013/03/long-and-short-term-approaches-for-tuning-force-com-performance.html

Q: スキニーテーブルのストレージコストは何ですか？

A: スキニーテーブルによって消費されるストレージは組織のストレージにカウントされません。

Q: スキニーテーブルの妥当性は何ですか？それを有効にした後に、期限切れしますか？

A: スキニーテーブルは期限切れしません。また、データがアップロードされるようにシステムによって自動的に更新されます。

Q: 新しい項目を作成した場合、それは自動的にスキニーテーブルへ追加されますか？

A: スキニーテーブルの既存項目のデータは自動的に更新されますが、新しい項目が作成された場合、スキニーテーブルは再作成される必要があります。

Q: スキニーテーブルの有効化を salesforce.com サポートへ依頼する必要がありますか。

A: スキニーテーブルは、レポート、リストビュー、または、SOQL クエリのパフォーマンスを向上させる場合は、それぞれの特定のケースを分析する際に、弊社のデータベースパフォーマンスエンジニアリングチームによって作成されます。

Q: 将来のリリースで、自分でスキニーテーブルまたはインデックスを作成するためのオプションが提供される計画はありますか？

A: 現時点ではその計画はありません。弊社はスキニーテーブルが実際に役に立っているかを確認するためにユースケースを分析したいと考えています。

Q: スキニーテーブルはデータストレージの制限の対象としてカウントされますか？

A: いいえ。スキニーテーブルは組織のデータストレージの対象としてカウントされません。

Q: スキニーテーブルが存在するとき、テーブル名、その他の方法で、それを確認することはできますか？Web UI で表示される物はありますか？または、お客様がどのスキニーテーブルが組織に存在しているのかを追跡する必要はありますか？

A: スキニーテーブルが存在しているとき、お客様へ表示される物はありません。それは完全に明白です。

Q: parent-detail オブジェクトから列を取得するためスキニーテーブルを作成することはできますか？

A: いいえ。使用するデータの非正規化を検討してください。例えば、親レコードから詳細レコードへ値をコピーするためのトリガ。

Q: ToDo オブジェクトにスキニーテーブルを作成することはできますか？

A: いいえ。活動（ToDo または、行動）にスキニーテーブルを作成することはできません。

Q: カスタムオブジェクトにスキニーテーブルを作成することはできますか？

A: はい。スキニーテーブルはカスタムオブジェクトに作成することができます。

Q: スキニーテーブルについての詳細な情報はどこで得ることができますか？

A: http://blogs.developerforce.com/engineering/2013/03/long-and-short-term-approaches-for-tuning-force-com-performance.html

Force.com クエリオプティマイザー FAQ

General Information

Required Cookies

Functional Cookies

Advertising Cookies

General Information

Required Cookies

Functional Cookies

Advertising Cookies

Cookie List