作为开发人员，我经常使用 SQL Profiler。这是一个很好的调试工具，既可以跟踪我的代码在做什么，也可以分析性能问题。
但是我一直在我的开发环境中使用它，并且以一种非常可控的方式使用它。
SQL Profiler 能否在生产环境中实际使用？
我首先担心的是它会降低性能。
我的第二个担忧是，因为它正在生产中，您不会触发有趣的操作本身。您必须让分析器长时间运行，然后分析结果。结果集会变得太笨拙吗？（占用太多磁盘空间，查询太难）。
有人在生产中使用 SQL Profiler 吗？
我在 SQL Server 2008 生产数据库上遇到了与事务相关的问题。简要概述一下，我们有一个网站，该网站在该州拥有众多并发用户，他们通过 ASP.Net 网站执行 GUI 类型的工作（添加记录、修改、查看等）。
每个插入和更新都在它自己的事务中完成，由数据访问层处理。我相信，数据库隔离设置为 Read_Commited。
一切正常。
但是，已添加一个新模块，该模块轮询单独的数据库以获取信息。如果有新信息，一个进程会启动一个新事务，并使用相同的数据访问器代码从我们的数据库中读取，以及从另一个单独的数据库中读取新信息。然后它会进行大量检查以查看它必须对新数据做什么......然后开始对我们的数据库进行大量更新或插入。这一切都在一个大交易中。来自 UI 应用程序和轮询服务的所有插入和更新都经过相同的 CRUD 过程。由于要处理的传入消息可能包含许多需要更新的实体，因此完成事务的时间可能在瞬间到一分钟之间。
但是我们发现，当处理较大的消息时，UI 会锁定，并且可以为用户锁定 3 分钟。
因此，我们认为在选择中添加“NOLOCK”提示可能会有所帮助。它没有。好吧，它可能有所帮助，但锁定仍在发生。
我认为原因可能是消息到达，并且启动了一个事务，这导致其他事务无法工作（即使是 SELECT 语句，我也不明白）。分析数据库表明，即使是简单的选择也需要很长时间才能在 UI 上完成（简单，例如SELECT fields FROM SingleTable WHERE PrimaryKey = Value
我们的索引似乎没问题……我们在所有表上都有触发器，它们只是将更新和插入复制到 AUDIT 数据库表中。不要认为他们是问题所在。
我认为这是因为围绕消息处理的事务，这将 UI 锁定。
任何人都可以分享经验或告诉我在哪里可以查看为什么我们会遇到 UI 锁定？UI 应该有优先权。消息处理是后台的事情......用户需要优先......但似乎消息正在锁定数据库......我们不确定UI是否曾经锁定消息处理。
希望有人可以提供帮助。我可以提供尽可能多的信息来提供帮助。