我有一个使用映射的批量触发器，以避免运行到SOQL调控器限制。此触发器还使用静态类变量进行递归和限制查询。
我正在做的是当在对象上启动诸如插入或更新的批量操作时，在这种情况下为Contact对象，然后触发器将在第一个触发器上构建相关Accounts的映射，并将使用这些其余触发器发射的地图。
以下是一个运行良好的操作示例，但仅适用于After Update＆amp;插入触发器操作后：
检查静态类变量是否为真。
如果变量不是真正的构建地图。
将静态类变量设置为true。
执行触发操作。
对于插入/更新触发器，会保持会话状态，并且在批量操作结束之前不会重置静态类变量。
但是对于之前的删除触发器，似乎没有会话状态，并且每次删除记录时都会重置会话。会话已重置，但调控器限制对于批量删除记录具有积极性。因此，使用before delete触发器，即使使用了map，soql查询计数也会继续计入臭名昭着的“Too Many Sql Queries”限制，以删除超过100条记录。
如何防止遇到SOQL限制的任何想法都将非常受欢迎。我无法在任何地方找到任何东西。
答案 0 :(得分：1)
您可以选择使用触发器来安排batch apex class for execution。对于哪个对象是启动级联删除的对象，使用触发器创建批处理的实例，并向其传递源ID列表。
然后在批处理类的execute方法中，您可以为每个批处理构建映射等，并在那里执行删除。批量顶点在同步执行的牺牲下具有相当高的调速器限制，表示该过程通常会在您操作的几秒钟内启动。
除此之外，它可能只是优化代码的情况，以便级联删除始终在列表上尽可能大（当然最多200个限制），或者您可以使用主详细信息关系来处理你的一些删除操作？