7

I became accustomed to add a LIMIT 1 clause at the end of my SOQL request when I want to request only one record. Even when I don't declare an array as result. For example:

Account account = [SELECT Name FROM Account WHERE Id = 'Example' LIMIT 1];

It's just a habit. I was thinking that this was more precise and so maybe faster.

So I wanted to know if there was a way to see if there is an impact in terms of perfomance.

Improve this question
2
  • 1
    @DanJones I agree that it's the same question, though our answers are quite different. Not that there's anything wrong with that! I think the vote makes sense.
    – Adrian Larson ♦
    Jan 5, 2017 at 17:40
  • 1
    @AdrianLarson Don't get me wrong, I'm not "defending my answer" or anything silly like that. :) I just remembered answering a similar question in the past is all!
    – Dan Jones
    Jan 5, 2017 at 17:43

1 Answer 1

Reset to default
12

In the case of assignment to a single record and filtering on an Id, there is zero impact on your governor usage. It won't affect CPU Time, and if you were already enforcing exactly one result by assigning to a single record, it won't affect heap size or query rows either. Obviously it won't affect number of queries. I can't think of any other relevant governors here.

In regards to CPU Time, note from Execution Governors and Limits (emphasis mine):

CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction. CPU time is calculated for the executing Apex code, and for any processes that are called from this code, such as package code and workflows. CPU time is private for a transaction and is isolated from other transactions. Operations that don’t consume application server CPU time aren’t counted toward CPU time. For example, the portion of execution time spent in the database for DML, SOQL, and SOSL isn’t counted, nor is waiting time for Apex callouts.

In terms of the Query Plan, there is no impact either, to Cardinality nor Cost. Note that only the most efficient plan is used, so while there is a curious third plan evaluated when you add the LIMIT clause, it does not effect run-time performance of the query.

Filter On Id, No Limit

  • Cardinality: 1
  • Cost: 0.00005636343140570398

  • Screenshot:

    Id Filter No Limit

Filter On Id, With Limit

  • Cardinality: 1
  • Cost: 0.000056363431140570398
  • Screenshot:

Filter On Name, No Limit

  • Cardinality: 1
  • Cost: 0.00016909029421711193

  • Screenshot:

    Name Filter No Limit

Filter On Name, With Limit

  • Cardinality: 1
  • Cost: 0.00016909029421711193

  • Screenshot:

    Name Filter With Limit

Improve this answer
5
  • Thanks for your answer. I'm sorry I don't really understand how it can be possible that DML statements don't impact CPU time. It must impact something no? Also, if the filter wasn't on the id, could it be useful?
    – Martin Lezer
    Jan 5, 2017 at 15:34
  • @MartinLezer Well, if you write a filter that could return thousands of records, and then you add LIMIT 1, of course it can affect query rows, heap size, etc.
    – Adrian Larson ♦
    Jan 5, 2017 at 15:36
  • 1
    Yes but imagine I have this query: Account account = [SELECT Id FROM Account WHERE Name = 'Example']. And I know I have only one record like this. This is just an example. My question will be: Does Salesforce stop searching for another account because of the variable declared which is not an array, or Salesforce needs the 'LIMIT 1' clause to be faster?
    – Martin Lezer
    Jan 5, 2017 at 15:40
  • Wow thanks for the time you spent to answer my question. I guess I have to change my habits...
    – Martin Lezer
    Jan 5, 2017 at 15:55
  • No it's not a bad thing. It's protective if, for instance, you're wrong that there is only one record with that name.
    – Adrian Larson ♦
    Jan 5, 2017 at 16:03

Not the answer you're looking for? Browse other questions tagged .