我不确定这是发布此问题的合适位置，尽管我是在编写相对复杂的SQL查询的上下文中找到的。如果不是，请接受我的道歉，如果我可以滥用您的善意，请指向适当的Stack Exchange社区，在那里我可以找到解决问题的方法。
我必须实施“简单”搜索;用户使用起来很简单，因为它只有一个字段，但实现起来相当复杂，因为在搜索字段中输入的任何表达式都可以用很多不同的方式解释，涉及多个表和关系。所以我决定将搜索分解为更简单的查询，每个查询根据一组特定的标准将一组id转储到表变量中。最后，我会将所有临时结果合并到一个集合中，加入任何缺少的字段并根据用户首选项对集合进行排序。结果似乎很准确，但有时表现令人惊讶且无法接受。
经过一些调查，我了解到如果表变量与SQL Server中的其他表连接，由于SQL Server不支持统计或跟踪表中的行数，可能会导致查询计划选择效率低下导致性能下降编译查询计划时的变量。但是，显然，我可以通过启用跟踪标志2453来改善这种情况，它允许表变量在更改足够数量的行时触发重新编译。实际上，时间从大约30秒下降到远低于1秒，所以我决定在使用包含可能很多行的表变量的其他查询中测试跟踪标志。
我没想到的是每次启用和禁用跟踪标志2453都会产生信息事件（类似于“DBCC TRACEON 2453，服务器进程ID（SPID）56。这只是一条信息性消息;没有用户操作是必需“）在SQL Server日志和操作系统事件日志中。但是我启用了跟踪标志的一些查询运行了很多次，这导致那些不需要用户操作的信息性消息泛滥两个日志，隐藏了可能需要用户操作的其他可能有用的消息。
通过一些额外的调查，我了解到跟踪标志2505可以阻止某些事件被记录，但在我的测试环境中（在Windows 7 SP1上运行SQL Server Express 2012），这并没有解决我的问题。
有人知道如何阻止这些邮件充斥日志吗？谢谢！