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?

Answer 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.

Answer 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.

Answer 3

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

Answer 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.