无论如何，经过一番搜索和阅读，我决定问一下。
来自我的问题：What are the first issues to check while optimizing an existing database?，其归结为必须强调加载作为备份.bak文件接收的本地SQL Server开发数据库。
我是否正确理解the answer by paxdiablo to question: "DB (SQL) automated stress/load tools?"没有通用压力加载测试独立于RDBMS的SQL工具？
SQL Server的压力测试加载工具有哪些？
你在为本地开发SQL Server数据库的廉价和肮脏压力加载做什么？
更新：我对压力加载SQL Server 2000,2005,2008数据库很感兴趣 （对2000年没有任何线索） 好吧，让我们放下最终/真实测试（对QA专家，DBA和系统管理员）并将问题限制在压力加载的背景下，以找出设计中明显（令人发指的）缺陷，性能瓶颈。
答案 0 :(得分：2)
你是对的。
没有通用的压力加载测试SQL工具独立于RDBMS。
怎么会有？您可以对硬件子系统进行吞吐量独立测试（例如SAN，网络），但数据库的性能在很大程度上取决于您的应用程序的访问模式，RDBMS的类型，硬件。
最好的办法是在代表性的硬件平台上 加载测试连接到数据库的应用程序 。有几种工具可以做，包括Ultimate version of Microsoft Visual Studio 2010。
答案 1 :(得分：2)
作为警告的一句话：很容易对alocal db进行压力测试，看看db设计是好/坏/缺失（坏指数等）。
尝试从中获取实时性能指标是徒劳的 - 即使有足够的内存（不太可能 - 大多数工作站与真正的数据库服务器相比都是糟糕的内存），您的光盘子系统将会被SUCK（100米高的字母）共同映射到什么是真正的数据库服务器可以抛出它。 Becasue普通开发本地数据库只有一个或两个光盘，而数据库服务器通常使用更多和更快的光盘。因此，工作站上的SLOOO可能是SLOOOOW，可能是服务器上的秒操作。
但是，再次出现了糟糕的索引使用情况。