TerraSky PowerNight Soql performance explained

Copyright © TerraSky Co., Ltd. All Rights Reserved. 1
TerraSky Power Night
2017年11月29日
株式会社テラスカイ
ソリューション本部
吉清隆之
SOQL Performance Explained

自己紹介
2Copyright © TerraSky Co., Ltd. All Rights Reserved.
吉清隆之
2017年1月テラスカイ入社（そろそろ満１年）
ソリューション本部第１ソリューション部部長
主に大型案件をやってます。
PM歴はうん十年、Salesforceは2011年から携わってます。
職歴
日本電気ソフトウェア（現NECソリューションイノベーター）
日本オラクル
NTTデータ
セールスフォース・ドットコム等々
資格
Salesforce: Sales Cloud,Service Cloud,上級アドミン
その他いっぱい（笑）

1. はじめに
Salesforceはパフォーマンスチューニングが出来ないのでしょうか。
そんなことはありません。一般的なDBよりはチューニング余地が少ないですが、イン
デックスを検討することで性能改善させることはできます。
是非、設計段階からパフォーマンスを意識した設計をしていきましょう。
また、SOQLが効率化されているかを確認することが出来ます。そのやり方も覚えま
しょう。
3Copyright © TerraSky Co., Ltd. All Rights Reserved.
SlowなSOQL
を改善しよう

4
2.インデックス比較
Copyright © 2016 Terrasky Co., Ltd. All Rights Reserved.
標準インデックスカスタムインデックス
項目
Id, Name, OwnerId, RecordTypeId,
Audit dates（SystemModStamp など）,
Division,Email (取引先責任者とリード)
参照関係項目と主従関係項目
とドキュメントには記載されてます・・
外部ID,ユニーク項目（管理者設定可）
標準インデックス対象外の任意の項目
（複数選択リスト, ロングテキストエリア,
リッチテキストエリア, 暗号化テキスト,
非決定性の数式ι¹には設定不可）
選択的
条件を満たすレコード全体のうち以下の
しきい値以下の場合
• 最初の100万件までは30%
• 100万件を超える分の15%
• 最大で100万件
例）
300万件：30万＋30万＝60万
560万件：30万＋70万＝99万
条件を満たすレコード全体のうち以下の
しきい値以下の場合
• 最初の100万件までは10%
• 100万件を超える分の5%
• 最大で333,333件
例）
300万件：10万＋10万＝20万
560万件：10万＋23万＝33万
非決定性数式¹
• 直接、間接に他オブジェクトの項目を参照している
• 常に同じ値を返すとは限らない関数 (TODAY や NOW など) を使用している
• 所有者、自動採番、ディビジョン、監査項目 (CreatedDateとCreatedByID以外)を参照している
• インデックス付けできない項目(複数選択リストなど)を参照している
• マルチ通貨組織における通貨項目を使用している
• 特殊な機能を持つ以下の標準項目を参照している

3. 抽出条件式 (where句) ①
• AND
• インデックス化項目に対する2つ以上の条件がAND結合されている
• 各インデックスを2倍のしきい値で選択性の高低判定
• 選択性の高い全てのインデックスの「積」を満たすレコード数がしきい値以
下なら、それら全てのインデックスが使用される
• 全てが標準インデックスなら、標準インデックスのしきい値
• 1つでもカスタムインデックスが含まれるなら、カスタムインデックスのし
きい値
• インデックスのいずれかから返されるレコード数が、オブジェクトのレコー
ド数の 20 % または合計レコード数 666,666 を超えない限り、インデッ
クスが使用される。

4. 抽出条件式 (where句) ②
• OR
• インデックス化項目に対する2つ以上の条件がOR結合されている
• 全ての条件項目に選択性が高いインデックスが存在し、かつ、各条件を満た
すレコードの「和」がしきい値以下なら、それら全てのインデックスが使用
される
• 全てが標準インデックスなら、標準インデックスのしきい値
• 1つでもカスタムインデックスが含まれるなら、カスタムインデックスのし
きい値
• すべてのインデックスから返されるレコード数が、オブジェクトのレコード
数の 10 % または合計レコード数 333,333 を超えない限り、インデック
スが使用される。
• LIKE
• Force.com クエリオプティマイザでは内部統計情報テーブルは使用されま
せん。代わりに、最大で 100,000 件の実際のデータのレコードを抽出し、
カスタムインデックスを使用するかどうかが決定されます。

5. インデックスが使われないケース
• 比較方法が一致しない「!=」「NOT IN」
• 『一致しない』は全件検索をしないとわかりません。可能であれば存在する
もののような逆の記述に変えましょう。
• 後方一致、中間一致 Like ％＿（ワイルドカード）
• 中間一致: 「次の文字列を含む」, Text__c LIKE ‘%Foo%’
後方一致: Text__c LIKE ‘%Foo’
SOSLでの検索を検討してみてください。
• 数値、日付、日付/時間以外の項目での範囲検索や大小比較
• Nullの検索
• 基本的にはNull検索はインデックスを使いませんが、カスタムインデックス
はSFDCサポートに依頼すればNullをインデックスに含めることは可能にな
ります。その場合はNullもインデックス検索で使用出来ます。

6. Think of what to do next
• 2列カスタムインデックス
• ２つの項目を複合してインデックスに出来る。例えば住所のように1つ目を都道府県、
2つ目を市区町村のように作成できる。2つ目の項目はNullでも可。項目個別にイン
デックスを作るより効果が高い。
• スキニーテーブル
• 特定オブジェクトの一部の項目のみでコンパクトに構成されたオブジェクト
• 主に大量のレコードを含むオブジェクトに対するクエリー(レポート、リストビュー、
SOQL)の性能を向上させるために利用される
• 対象オブジェクトの持つ項目のうち、100項目までをスキニーテーブルに含められる
• 組織のデータストレージの対象としてカウントされません。
• ディビジョン
• データを論理セクションへ分割する。
• ひとつのオブジェクトに 100 万を超えるレコードがある場合、および、35 を超える
ライセンスがある場合に有効化できる。

7. 実装にあたって
• 効率的なインデックスの机上検討
• オブジェクトのレコード数、項目のカーディナリティ検索条件、選択されるレ
コード数の想定をしてインデックスの利用を机上検討
• 検証
• SOQLを作成し、統計情報を取って効果的かを確認。
• 更なる検討
• 統計情報の結果から、再度検討そして検証の繰り返し。
２列インデックスやディビジョン、スキニーテーブルも検討してみましょう。
• デメリットの理解
• インデックスは別オブジェクトとして作成されます。そのためインデックスが
多いと更新処理のパフォーマンスが劣化します。

8. インデックスが使われているかを確認する方法
• 開発者コンソールでQuery Planを取得しましょう。
• インデックスがある場合は2行以上結果が表示されます。
• SalesforceはCostが低いものを選択します。Costは1以下を目標としましょう。
• Cardinalityは選択対象の件数です。先に説明したインデックスのしきい値がこち
らに該当しますので注意しましょう。
詳しくはTerrasky TechBlogで！

9. おまけ
SOSL
SOSLで、リストビュー内の検索が新しくサポートされるようになりました。
リストビュー内の検索
USING ListView を使用すると、オブジェクトのリストビューを検索でき、大きなリ
ストビューから 1 件のレコードを容易に探すことができます。
次の SOSL ステートメントは MVP Customers リストビューで Acme の Account
オブジェクトを検索しています。
FIND {Acme} IN ALL FIELDS RETURNING
Account(Id, Name USING ListView=MVPCustomers)

TerraSky PowerNight Soql performance explained

More Related Content

More from TerraSky

TerraSky PowerNight Soql performance explained