作为一名开发人员，我经常使用SQL Profiler。 这是一个很好的debugging工具，既可以跟踪我的代码正在做什么，也可以分析性能问题。
但是我总是在我的开发环境中以一种非常可控的方式使用它。
SQL事件探查器是否可以在生产环境中实际使用？
我首先关心的是会降低性能。
我的第二个担忧是，因为它在生产中，所以你不会触发有趣的动作本身。 您将不得不离开长时间运行的分析器，然后分析结果。 结果会太难处理了吗？ （占用太多的磁盘空间，太难查询）。
有没有人在生产中使用SQL Profiler？
完全披露：我已经在数据库pipe理员testing版网站上发布了相同的问题。 想要支持DBA stackexchange站点的Serverfault成员有机会回答那里的问题，而不是在这里。
是的，监督行为需要一些资源。 在超载的服务器上运行它可能会杀死它。
你实际上会监控真实的生活负载：你的行为可能会在这个负载的噪音中消失。
有时我们在生产上运行它。 主要针对特定的代码使用文本filter，或使用CPU /持续时间filter来捕获更长时间的运行。 而我们并不试图捕获XML执行计划或一些这样的非现实
关键是要知道你在找什么：我们不倾向于离开它，陷入一切。
在这种情况下，如果您想查看某些操作的结果，可以在几小时之内完成操作吗？