哇，这个标题立刻给了我“你问的问题似乎很主观，很可能会被关闭。”
无论如何，经过一番搜索和阅读，我决定问它。
来自我的问题：优化现有数据库时首先要检查的问题是什么？，这归结为需要强调加载作为备份 .bak 文件接收的本地 SQL Server 开发数据库。
我是否正确理解了 paxdiablo 对以下问题的回答：“DB (SQL) 自动压力/加载工具？” 没有独立于 RDBMS 的通用压力负载测试 SQL 工具？
SQL Server 的压力测试加载工具有哪些？
你在为本地开发 SQL Server 数据库的廉价和肮脏的压力加载做什么？
更新：而且我对压力加载 SQL Server 2000、2005、2008 数据库感兴趣（对 2000 没有任何线索）。
好的，让我们把最终/实际测试放在一边（对 QA 专家、DBA 和系统管理员），并将问题限制在压力负载的上下文中，以发现设计中的明显（令人发指的）缺陷、性能瓶颈。
你是对的。
没有独立于 RDBMS 的通用压力负载测试 SQL 工具。
怎么可能呢？您可以单独对硬件子系统（例如 SAN、网络）进行吞吐量基准测试，但是数据库的性能在很大程度上取决于您的应用程序的访问模式、RDBMS 的类型、硬件。
最好的办法是在有代表性的硬件平台上对连接到数据库的应用程序进行负载测试。有几个工具可以做，包括Microsoft Visual Studio 2010 的终极版。
一句话警告：很容易对本地数据库进行压力测试，以查看数据库设计是否好/坏/缺失（坏索引等）
试图从中获得实时性能指标是徒劳的——即使有足够的内存（不太可能——与真正的数据库服务器相比，大多数工作站的内存都很糟糕）你的磁盘子系统将 SUCK（100 米高的字母）与真正的db 服务器可以扔给它。因为普通的开发本地数据库只有一张或两张磁盘，而数据库服务器通常使用更多和更快的磁盘。因此，您的工作站上的 Waht 可能是 SLOOOOW 可能是服务器上的几秒钟操作。
但是再一次，像糟糕的索引使用这样的事情是可见的。