使用单独的架构如何影响SQL Server 2008的性能？

我想在SQL Server 2008数据库中为具有不同目的的对象使用单独的架构。现在，我们使用一种令人费解的命名约定来表示表或存储过程的目的，并且前缀意味着我们必须扫描五个或六个xharacter才能看到唯一名称的开头。我想为仅用于驱动UI的表（菜单，人员角色等）和维表与事实表等使用单独的架构。

我的问题是，使用多种架构（方案？）会对所有事情都使用旧的dbo产生性能影响吗？

尽管影响很小，但可能会影响查询优化器的性能，具体取决于您的编码风格。如果引用的表没有模式，那么优化器必须首先尝试通过检查用户默认模式（如果有）中的表，然后使用dbo。，然后使用其他所有方法来识别表。如果您将这些表显式引用为schema.table，那么无论如何这都是一个好习惯，那么即使是很小的开销也可以避免。

性能无差异。但是，您现在正在使用架构（即使您不知道）。

使用对不符合模式资格的模式对象（例如表，存储过程，UDF等）的引用确实会对性能产生影响。引用应始终由模式限定。此类不合格的引用必须得到解决，并且发生这种情况：

• 首先，在建立会话的用户的默认架构下查找具有相同名称和类型的对象（例如jsmith）。如果找到，则使用该实例。
• 否则，请在schema下查找具有相同名称和类型的对象dbo。

这有几个影响：

• 在大多数情况下，需要两次查找来解析引用，而不是如果引用是架构限定的，则只需要一次查找。
• 绑定查询/存储过程/用户定义函数时获得的执行计划无法缓存和重用。

当发生故障时，您只会痛苦地发现最终的结果是，不同的用户可能从给定的查询或存储过程中获得不同的结果。select * from foo join bar作为数据库所有者，类似的东西对我来说可能很好。对于在相同数据库中jsmith无意间创建了foo以其自己的模式（jsmith.foo）命名的表的用户而言，它可能会被破坏。

出于这个原因，也create和drop报表应架构资格创建或删除的对象的名称。