Governor Limits — Best Practices & Elastic Limits

好，同学们，接下来我们聊一聊在 Salesforce 开发中，如何避开调控器限制，写出高效的 Apex 代码。这就像给你的程序戴上安全帽，避免它因为超载而崩溃。 首先记住一个大原则：，永远不要一条一条地处理数据，要一次处理一批。， 比如说 DML 操作，如果你在一个循环里每次插入一条记录，每一条都会消耗一次 DML 限制，几百条下来很容易碰到墙。正确的做法是，先把所有要处理的数据放进一个列表，循环结束后再用一条 DML 语句统一处理。这种“收集成列表，一次操作”的方式，能成百上千倍地降低限额的消耗。 同样，SOQL 查询也不能放在循环里。如果你的代码在 for 循环中每次都查询数据库，调控器会很快把你拦下。这里的技巧是：先用一个集合（比如 Set）把需要查的 ID 或字段值收集起来，然后用带 IN 子句的 SOQL 一次性取出所有相关记录。Set 能自动去重，效率很高。 那么，如果查询返回的数据量可能非常大，我们该怎么做呢？Apex 提供了一个专门的安全模式：，SOQL for 循环，。写法是 `for (MyObject obj : [SELECT ...]) {}`。这种方式下，Apex 会分批从数据库获取记录，而不是一次性把所有结果加载到内存里。这样既避免了堆空间用尽，也撑住了调控器的查询行数限制。对于几十万、上百万条记录的大查询，这是推荐的官方模式，请一定用起来。 接下来，为了让查询跑得又快又省限额，我们还要学会 ，“选择性查询”，。说白了，就是要尽量用索引字段来过滤。比如有索引的字段有主键、外键、唯一字段，或者在后台被标记为索引的。在你的 WHERE 子句里优先用这些字段，能极大减少数据库扫描的范围，查询更高效，限额也消耗得更少。 刚提到了限制，还有一个贴心的新功能要告诉你。Salesforce 推出了 ，弹性限制（Beta），。有些批量作业啊，比如 Scheduled Jobs，每日的异步 Apex 执行数量有限额。如果你们的业务量突然增大，超过了默认的 250,000 次执行，弹性限制可以让你以受控的速率继续处理，不会粗暴地把作业杀掉了。它就像给高速路开了个缓行区，虽然慢一点，但还能走。 最后，我们有义务时刻监视自己的代码是否快要踩线。你可以在 Apex 设置里打开 ，控管者限制电子邮件警告，。当你的代码消耗掉任何一个限制的 50% 时，系统就会给你发邮件提醒，让你有机会在发生致命异常前赶紧优化。这就像车子仪表盘上的油量警告灯，提前提醒，避免半路抛锚。 好了，总结一下这节课的重点： - 把 DML 搜集起来批量做。 - 绝不在循环里跑 SOQL，用 Set 配合 IN 子句。 - 查询海量数据用 SOQL for 循环。 - 利用索引字段让查询具有选择性。 - 了解弹性限制，给紧急作业一条活路。 - 打开 50% 警告邮件，保持警惕。 把这些习惯内化，你的 Apex 代码就能在 Salesforce 的“交通规则”里安全顺畅地跑起来。下次课我们继续深入看具体的优化案例，谢谢大家。