【Salesforce】ガバナ制限一覧

Salesforceエンジニアの友達！ガバナ制限について書いていきます。

公式の説明は[コチラ](https://developer.salesforce.com/docs/atlas.ja-jp.210.0.apexcode.meta/apexcode/apex_gov_limits.htm)

# 発行されるSOQLクエリの合計数

このガバナ制限に出会えるコードはこう！

```
for(Integer i = 0; i < 101; i++){
    List<Account> accList = [SELECT Id FROM Account];
}
```

表示されるエラーはこう！

```
System.LimitException: Too many SOQL queries: 101
```

デバッグはこう！

```
Number of SOQL queries: 101 out of 100 ******* CLOSE TO LIMIT
```

for文の中でSOQLを書けばすぐに出会えます。

今まで参画したプロジェクトでは1回しか見たことありませんが、見つけたときが改修案件だったので戦慄しました。

「こ・・・このレベルのコードを修正していくのか・・・」と

他にも大型案件だとあっちのクラスが呼ばれ、こっちのクラスが呼ばれ・・・となり、上記のエラーになったりしたので、そういった場合はむやみにSOQLを書くのではなく、DAOクラスを用意したほうがいいと思います。(設計段階になると思いますが・・・)

当ガバナ制限を回避するために、非同期制限をするってことはしたことが無いですね。

# SOQL クエリによって取得されるレコードの合計数

このガバナ制限に出会えるコードはこう！

```
// 50,001件以上のレコードが存在するオブジェクトに対してWHEREやLIMITを使用せずにSOQLを書く
List<Account> accList = [SELECT Id FROM Account];
```

表示されるエラーはこう！

```
System.LimitException: Too many query rows: 50001
```

デバッグはこう！

```
Number of query rows: 50001 out of 50000 ******* CLOSE TO LIMIT
```

to C系のコールセンターでよく見られるガバナ制限ですね

to C系だとCaseの数が膨大になるので・・・

普通にWHEREやLIMITで回避できます。

常日頃、必要なレコードのみ取得するように意識！

# Database.getQueryLocatorによって取得されるレコードの合計数

このガバナ制限に出会えるコードはこう！

```
// 10,001件以上のレコードが存在するオブジェクトに対してWHEREやLIMITを使用せずにSOQLを書く
String query = 'SELECT Id FROM Account';

Database.QueryLocator dq = Database.getQueryLocator(query);
```

表示されるエラーはこう！

```
System.LimitException: Too many query locator rows: 10001
```

デバッグでは特に書いてないですね

<img width="156" alt="無題.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/492812/d1c815f8-a65b-2fc5-93fc-2eb01c7971ba.png">

こちらも[SOQL クエリによって取得されるレコードの合計数]と同様、WHEREやLIMITで回避できます。

SQQLとDatabase.getQueryLocatorってどう違うのって知りたい方は[コチラ](https://web.plus-idea.net/2017/01/database-query-getquerylocator-diff/)の方のブログに書いてあります。

# 発行されるSOSLクエリの合計数

このガバナ制限に出会えるコードはこう！

```
for(Integer i = 0; i < 21; i++){
    List<List<SObject>> searchList = [FIND 'Test' IN ALL FIELDS RETURNING Account(Name)];
}
```

表示されるエラーはこう！

```
System.LimitException: Too many SOSL queries: 21
```

デバッグはこう！

```
Number of SOSL queries: 21 out of 20 ******* CLOSE TO LIMIT
```

SOSLはあまり経験が無いですねー

1回あったかな？という感じです。

こちらもfor文内で書かなければ大丈夫かと思います。

# 1 つのSOSLクエリによって取得されるレコードの合計数

~~このガバナ制限に出会えるコードはこう！~~
※まだ出会えてない

```
List<Account> accList = [SELECT Id, Name FROM Account WHERE Name = 'test'];
System.Debug('★★ 変数 accList.size() ： ' + accList.size());

List<List<sObject>> searchList1 = [FIND 'test' IN ALL FIELDS RETURNING Account(Name)];
Account[] searchAccounts1 = (Account[])searchList1[0];
System.Debug('★★ 変数 searchAccounts1.size() ： ' + searchAccounts1.size());
```

SOQLだと600なのにSOSLだと250・・・
まだ理解が足りてないのかなー

```
★★ 変数 accList.size() ： 600
★★ 変数 searchAccounts1.size() ： 250
```

# 発行されるDMLステートメントの合計数

**※随時更新中**

# DMLステートメントの結果として処理されるレコードの合計数、Approval.process、またはdatabase.emptyRecycleBin

**※随時更新中**

# insert、update、またはdeleteステートメントによって繰り返しトリガするApex呼び出しのスタックの深さの合計数

**※随時更新中**

# トランザクション内のコールアウト(HTTP要求またはWebサービスコール)の合計数

**※随時更新中**

# トランザクション内のすべてのコールアウト(HTTP要求またはWebサービスコール)のタイムアウトの最大累積値

**※随時更新中**

# Apex呼び出し1回につき許可されるfutureアノテーションを持つメソッドの最大数

**※随時更新中**

# System.enqueueJobによってキューに追加されるApexジョブの最大数

**※随時更新中**

# 許可されるsendEmailメソッドの合計数

**※随時更新中**

# ヒープの合計サイズ

【コード面での改善】
・クラスに不要なプロパティを持っている場合は削る。
・DTOやsObject内部の不必要な項目を保持していないかを調査し、削る。
・別途、集計オブジェクトを実装し、そちらを参照するようにする。

# Salesforceサーバの最大CPU時間

**※随時更新中**

# Apexトランザクションごとの最大実行時間

**※随時更新中**

# Apexトランザクションごとに許容される転送通知メソッドコールの最大数

**※随時更新中**

# 各転送通知メソッドコールで送信できる転送通知の最大数

**※随時更新中**