Does using fully qualified names affect performance?

Question

Does the use of fully qualified table names in SQL Server have any affect on performance?

I have a query where I am joining two tables in different databases. A DBA has suggested to omit the database name on the host query, which I am guessing is either for performance or a convention.

All tables fully qualified

USE [DBFoo]
SELECT * FROM [DBFoo].[dbo].[people] a
INNER JOIN [DBBar].[dbo].[passwords] b on b.[EntityID] = a.[EntityID]

Preferred?

USE [DBFoo]
SELECT * FROM [dbo].[people] a
INNER JOIN [DBBar].[dbo].[passwords] b on b.[EntityID] = a.[EntityID]

Does this actually make a difference?

Solution 1

Fully qualified names are usually preferred, but some considerations apply. I will say it depends a lot on the requirements and a single answer may not suffice all scenarios.

Note that this is just a compilation binding, not an execution one. So if you execute the same query thousand times, only the first execution will 'hit' the look up time, which means lookup time is less in case of fully qualified names. This also means using fully qualified names will save the compilation overhead (the first time when query is executed).

The rest will reuse the compiled one, where names are resolved to object references.

This MSDN Article gives a fair guidance on SQL Server best practices. (Check the section named: How to Refer to Objects)

This link explains in more details on set of steps done to resolve and validate the object references before execution: http://blogs.msdn.com/b/mssqlisv/archive/2007/03/23/upgrading-to-sql-server-2005-and-default-schema-setting.aspx

Going through the second link, the conclusion says that:

Obviously the best practice still stands: You should fully qualify all object names and not worry about the name resolution cost at all. The reality is, there are still many imperfect applications out there and this setting help great for those cases.

Also, in case the database name change is not allowed on production environment, you may then think to include database names in fully qualified names.

Solution 2

Does the use of fully qualified table names in SQL server have any affect on performance?

There's a trivial penalty because the query text is longer so there's more bytes to be sent to SQL Server and parsed.

The penalty is academic, honesty it will not be better or worse because of the prefixes.

If you observe a difference in performance, it may be because the query text is different and SQL Server has generated a different plan. If the conditions (statistics, whatever else) do not change between running the queries then in all likelihood SQL Server will generate a 100% identical plan. If conditions have changed between the prefixed and unprefixed queries being run then one plan may be better than another.

Although in that scenario, the performance difference is not because of the prefixing. If you evicted the plans from the plan cache and ran them again (thus giving SQL Server a chance to generate plans under the same conditions) you should see both queries with the same plan.

There is significance for qualifying object names (see CREATE VIEW ... WITH SCHEMABINDING) but there aren't consequences for performance.

Solution 3

Having DB prefix will cause issue if you migrate or rename the DB Name. That could be the reason why DBA advised so

Solution 4

Does the use of fully qualified table names in SQL Server have any affect on performance? Yes. Reusing plan caches eliminates requirement to "recompile" a plan.

BTW: Research parameter sniffing so plan reuse doesn't adversely impact performance... the flip side.

MSDN: The algorithms to match new SQL statements to existing, unused execution plans in the cache require that all object references be fully qualified. For example, the first of these SELECT statements is not matched with an existing plan, and the second is matched:

SELECT * FROM Person;

SELECT * FROM Person.Person;

Source: https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx

So, MSDN considers schema.name as fully qualified name, which matches. Not convinced this correlates with best practice of aliasing tables, required for intellisense to be helpful... muddy waters.

View more solutions

Comments

[paulsm4]

No. There is no runtime performance gain using "foo.dbo.people" vs. using "people". Or vice versa. Book recommendation: "Inside SQL Server", Kalen Delaney et al.

[Martin Smith]

That is talking about schema qualifying (two part names) not three part names. I would definitely avoid three part names inside DB objects (procedures etc) as it means if the DB is ever renamed or restored under a new name they will need to be changed.

[R.C]

@Martin: The MSDN article says: To reference an object located in a remote database, the fully qualified object name includes the server name and the database name. This is why MSDN article was referred to take more Ideas. Even the conclusion part of MSDN confirms the same : Always refer to the objects using a fully qualified name. At the very least, use the schema name followed by the object name. And yes, Database names can change. However Its more of Unlikely to happen in Production scenarios. Even in Testing scenarios ( UAT ) it happens rarely.

[R.C]

Msdn Also says: The assessment process can be improved by using either the fully qualified name or the DEFAULT_SCHEMA option. I will say It depends a lot on the requirements and a single answer may not suffice all scenarios. Database name changes are possible but so far I beleive it is against the standard practice followed by many organizations. Since we usually have database names in connection strings stored in web.config ,for example. This will definitely affect all the applications deployed to Production environment.

[R.C]

@ Martin: thanks friend for pointing out one important point. I just didn't wanted to include too many details and create confusion. So i just gave links to article to see each and every detail that suits one's requirements. Just added last line in my answer for this important point.

[John K. N.]

It's still an issue if the [DBBar] database name changes. Which in turn makes for a strange DBA recommendation as per your reasoning.