同一物理机和同一服务器实例上的 SQl 2008 跨数据库性能
在同一台物理机上的另一个数据库上进行选择时是否会对性能造成影响？因此，我在同一台物理机器上有 2 个数据库，在同一个 SQL 2008 实例中运行。
例如，在 SomStoreProc on_this_db 中，我运行
SELECT someFields FROM the_other_db.dbo.someTable
到目前为止，从我在互联网上读到的内容来看，大多数人似乎都表示“否”。
Is there any performance hit when doing a select across another DB on the same physical machine? So I have 2 databases on the same physical machine running within the same SQL 2008 instance.
For instance in SomStoreProc on_this_db I run
SELECT someFields FROM the_other_db.dbo.someTable
So far from what I have read on the internet, most people seem to indicate NO.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
即使这不会影响性能，也可能会导致数据完整性问题，因为无法跨数据库强制执行 FK。
然而，你的过程更有可能需要调整，特别是如果它们有数千行那么长。首先查找游标、相关子查询和错误索引。还要查找不可修改的 where 子句和逐行运行的标量函数。
当然，证明单独的数据库不是问题的最佳方法是采用一个缓慢的过程并将这些表转换为一个数据库并测试两种方式的性能。请至少说服他们进行这个较小的测试，然后再对一个数据库进行极其复杂且耗时的更改，然后发现他们仍然存在性能问题。
请记住，执行计划是你的朋友正在看这些东西。
Even if it is not a performance hit, it could be a problem in data integrity as FKs can't be enforced across databases.
However, it is more likely your procs need to be tuned especially if they are thousands of lines long. To begin with look for cursors, correlated subqueries and bad indexing. Also look for where clauses that are nonsaragable and scalar functions that are runing row-by-agonizing-row.
Of course the best way to prove that the separate database is not the issue is to take one slow proc and convert those tables to one database and test performance both ways. Please at least convince them to do this smaller test before they go ahead and make the horribly complicated and time consuming change to one database and then find out they still have performance problems.
And remember, the execution plan is your friend is looking at these things.