A blog dedicated to Salesforce Ohana

Query Plan Tool from Salesforce - A Hidden Gem

Query Plan in the developer console can help to speed up SOQL queries done over large volumes of data. This is such a powerful tool when dealing with bad performance. Developer can use this tool to optimize and speed up SOQL queries.

We can enable Query Plan in the Developer Console by -


Before we go into details, it's better to understand how Salesforce uses indexes while running the SOQL. As we all know it is always good to go for selective query instead of full table scan. But even with selective query, when we are using different filter criteria, it is not always the best SOQL query we are writing. The reason behind is that just writing where clause in the query does not guarantee that the filter is selective. So it is very important to understand which are the fields are good to be used in filter. Let's understand that first in the below section -
  • All we need to use is the indexes in the filter.
  • If we are using filter on standard fields, then we are using index if -
    • it is primary key (Id, Name, OwnerId)
    • it is a foreign key (CreatedById, LastModifiedById, Lookup, Master-Detail)
    • it is an audit field (CreatedDate, SystemModstamp).
  • If we are using filter on custom fields, then we are using index if that field is marked as Unique or External Id.
Without indexed filter, the query will not be considered for optimization. 

So does that mean if I use filter which is indexed, I am safe and my query is optimized? Answer is Yes and No.

Why Yes, because definitely using indexed field in filter clause will make the query optimized, but there is a catch which I am going to explain now -

When SOQL query is using indexed field, Salesforce will determine how many records it would return. For example -

  • For a Standard index, the threshold is 30% of the first million targeted record and 15% of all records after that first million. In addition to that, selective threshold for a standard index maxes out at 1 million (which is only possible if the total number of records is 5.6 million).
  • For a Custom index, the threshold is 10% of the first million targeted record and 5% of all records after that first million. In addition to that, selective threshold for a standard index maxes out at 333,333 (which is only possible if the total number of records is 5.6 million).
So if the filter exceeds the threshold, then query will not be considered for optimization.

Query Plan will provide us the below information about the SOQL query -

Now with the above information, let's execute few queries and analyze the result -

Query 1: Select count() from Contact
Result: 

Here I am not using any index field, Field column is blank, Operation Type is TableScan and cost is > 1. Anytime the cost of a SOQL query is greater than 1, it means it is not considered for Optimization.

Query 2: Select count() from Contact Where External_Id__c = '0xP1500100KXFU4512'
Result: 

Here I am using custom index field (External_ID__c) which is there in the Field column, Operation Type is Index and cost is < 1. Since we have one cost which is less than 1, that will be used to optimized the query.

Query 3: Select count() from Contact Where External_Id__c != '0xP1500100KXFU4512'
Result: 

Here I am using custom index field (External_ID__c) but still the field column in blank and Operation Type is TableScan and cost is > 1. So definitely this query is not optimized. But Why??
The reason is -
There are few unsupported operations which will make your query not good enough for optimization. They are as mentioned below -

Query 4: Select count() from Contact Where External_Id__c = '0xP1500100KXFU4512' and Contact_Type__c = 'Customer'
Result: 

Here I have used second indexed field(Contact_Type__c) in the query. In this scenario, Salesforce will select the plan with lowest cost.

Query 5: Select count() from Contact Where External_Id__c = '0xP1500100KXFU4512' And Client_Status__c = 'Active'
Result: 

Here I have used second non-indexed field(Client_Status__c) in the query. That is why only one indexed field in the result.

Query 6: Select count() from Contact Where External_Id__c = '0xP1500100KXFU4512' Or Client_Status__c = 'Active'
Result: 

Here I have used second non-indexed field(Client_Status__c) in the query with or condition.When using OR condition, all filters must be indexed and under the 10% threshold.

Query 7: Select count() from Contact Where Contact_Type__c = 'Customer'
Result: 

Here even though I have used indexed field(contact_type__c), but still the query is not optimized as you can see the lowest cost is also greater than 1. The reason is that here the finding variable 'Customer' is resulting more than 10% of the full table.

Query 8: Select count() from Contact Where Contact_Type__c = 'Advisor'
Result: 

Here I have changed the binding variable to 'Advisor' and resulting data count is less than 10% of the full table. That is why this query is optimized.

You can go through the below articles to go through more examples -





Share:

No comments:

Post a Comment

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (98) Apex (43) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (17) 501 (16) SOAP (13) tutorial (11) Certification. (9) lightning (8) Trigger (7) test class (7) unit testing (7) design pattern (6) report (6) security (6) trailhead (6) Advanced Admin (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) developer (5) formula (5) javascript (5) mobile (5) salesforce release (5) service cloud (5) solution management (5) use case (5) JSON (4) Lightning Experience (4) WebSphere (4) best practice (4) cast iron (4) component (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Certification (3) Live Chat (3) Performance (3) Products (3) Sales Cloud (3) Study Notes. (3) Summer15 (3) Tips (3) deployment (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Advanced Apex (2) Bulkify (2) Data Architecture and Management Certification (2) Distributed Version Controlling (2) Eclipse (2) Einstein (2) Force.com IDE (2) Governor Limit (2) IBM (2) Kitchener Developer Group (2) Lightning Design System (2) Live Agent (2) Online Event (2) Price Book (2) REST (2) SOSL (2) Spring 15 (2) Summer17 (2) ant (2) automation tool (2) basic (2) chatter (2) coding (2) communication (2) console (2) controller (2) documentation (2) flow (2) git (2) jquery (2) logging (2) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Agent Productivity (1) Analytics (1) Architect (1) Asynchronous callout (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Classic (1) Contact Center (1) Continuation (1) Continuous Integration (1) Cookie (1) Custom Metadata (1) Custom Object (1) Decorator Design Pattern (1) Diwali (1) Email (1) FSC (1) Financial Services Cloud (1) Goals (1) Groups (1) Guide (1) Household (1) Ideas (1) Implicit Sharing (1) Improvement (1) JourneyToCTA (1) KPIs (1) Kitchener User Group (1) Large Data Volume (1) LastModifiedDate (1) Metadata (1) Metrics (1) Omni-Channel (1) Opportunity (1) Person Account (1) Photo (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Role (1) Salesforce Optimizer (1) Session (1) Sharing (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Switch (1) SystemModStamp (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (1) agile (1) app (1) approval process (1) aura (1) awesome (1) backup (1) bitbucket (1) book (1) campaign (1) change set (1) code (1) code coverage (1) configuration (1) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (1) dreamforce (1) duplicate (1) dynamic (1) equals (1) error (1) field-level security (1) folder (1) ftp (1) generic (1) gift (1) global describe (1) hashcode (1) import wizard (1) jenkins (1) keynote (1) long running requests (1) monitoring (1) mysql (1) object (1) page layout (1) personal (1) power of one (1) record type (1) relationship (1) request (1) review (1) sub-tab (1) tab (1) username (1) visual workflow (1) workflow (1)

Total Subscribers

Total Pageviews