The internet is swimming with examples of really inefficient TSQL code. Just because everyone does it that way doesn’t make it optimal. I’ve already blogged about the issues you will find with NOLOCK hints, this post show that using system functions correctly can result in your Data Definition Language (DDL) running 3 times faster.
Example 1: Faster way to check existence of a table (object)
Common but Slowest
If you Right Click on a Table in SQL”s Management Studio you may enjoy the benefits of “Script Table As…”. Among other options it lets you create a script to “DROP AND CREATE”. It will generate a script similar to
-- Common Style of DML Check, then Drop & Create a table. IF NOT EXISTS ( SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.MyTable') AND type IN (N'U') ) CREATE TABLE dbo.MyTable(Rep_ID INT Null)
For this discussion I’d draw your attention to the TSQL that searches for existence of the user table ie:
-- Popular Approach SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.MyTable') AND type IN (N'U')
Better use of System function & faster
A quick read of SQL’s Books Online will make you aware that the SQL Function OBJECT_ID() has a 2nd parameter that lets you specify the type of the object you are searching for. If you use it, you will find that your query runs twice as fast. Why? There was no need to test the condition on the Type column separately.
-- Better: Use the 2nd Parameter instead of an AND - Same results but neater SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.MyTable', N'U')
You may have read that “SELECT *” was inefficient & you should always specify the columns you need. That is very true, in most circumstances. The exception to the rule is when the select is part of the “EXISTS” clause as it is here. In this case, the SQL Optimiser is smart enough to know that it only needs to know if a row is returned & doesn’t care about any of the columns in the select list. So performance in the following alternative is exactly the same. Use whatever you prefer, either alternative is slower than the last alternative.
-- Better: Use the 2nd Parameter instead of an AND - Same speed as SELECT * SELECT 1 FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.MyTable', N'U')
As the OBJECT_ID() function can be used in all TSQL, there is no need to wrap it up in a SELECT statement. It returns NULL if the object is not found so just compare its output to NULL. e.g:
-- Faster: just use the function & 2nd parameter - 3 Times faster IF OBJECT_ID(N'dbo.MyTable', N'U') IS NOT NULL CREATE TABLE dbo.MyTable(Rep_ID INT Null) --Only save millisecs here but same applies with any IF EXISTS which could be way more expensive. (Use an index instead of table scan etc.)
Not only is this is 3 times faster. It means less code, so less chance of making errors. Most importantly it avoids the bad (& unsupported) practice if querying the system tables directly (in this case sys.objects).
In case you haven’t heard, you should be using the Informational Schema Views & System Functions instead of the system tables because Microsoft may change the system tables between releases which will break all your code. Yes I know “everyone” does it. Yes I am a hypocrite as many of my tuning tools are very vulnerable to System Table changes. But Microsoft was saying this from Version 1.1 (in 1990) they never changed & DBA’s got blasé about it. But 15 years later with the release of SQL 2005 we found sysobjects became sys.objects. While they did a great job of backward compatibility it does highlight the risk you take using System Tables in the heart of your application.
You might wonder “why didn’t the SQL Server Management Studio doesn’t produce a better example of code. Surely they know how”. The tools team were likely to have a different goal to you. They were writing a context menu function that worked anywhere in the Object Explorer tree; Tables, Views, Functions Indexes etc. While many of these objects can be handled by OBJECT_ID(), some can’t. So it is more expedient to write a generic routine what worked everywhere than to produce optimal code samples with heaps of special case code. Especially when in this case the % improvement my be huge, but the actual time saved is still measured in millisecs, so who cares.
This blog is about the concept of system functions. And for some queries it makes a huge difference.
Example 2: Faster way find indexes on User Tables.
Perhaps you want to see all the Indexes in your system but don’t want the results cluttered with indexes on the System Catalog. Unfortunately when you query the Sys.Indexes table it doesn’t tell you if the Index is on a User Table, a System Table or an Indexed View. So you find yourself frequently joining on the Sys.Objects table & filtering with Type = N’U’ eg:
-- 2 table join to filter on User Tables. SELECT OBJECT_SCHEMA_NAME(I.object_id) AS [Schema], OBJECT_NAME(I.object_id) AS [Table], I.* FROM sys.indexes AS I JOIN sys.objects AS O ON O.object_id = I.object_id WHERE O.type = 'U'
Often I’ve found that I needed to think about indexes on Indexes views too. So it was better just to filter out all system objects than to limit my query to User Tables. So the query changes to :-
-- 2 table join to filter out System Objects. SELECT OBJECT_SCHEMA_NAME(I.object_id) AS [Schema], OBJECT_NAME(I.object_id) AS [Table], I.* FROM sys.indexes AS I JOIN sys.objects AS O ON O.object_id = I.object_id WHERE O.schema_id <> 4
But as I only wanted to filter the System Objects out of the Sys.Indexes Table I didn’t need the join with sys.objects at all. As I have the Object_ID I could use OBJECT_ID() or OBJECT_SCHEMA_NAME() to remove rows I didn’t like. eg:
-- Single table scan, Filtered by System Function, nearly 4 times faster. SELECT OBJECT_SCHEMA_NAME(I.object_id) AS [Schema], OBJECT_NAME(I.object_id) AS [Table], I.* FROM sys.indexes AS I WHERE OBJECT_SCHEMA_NAME(I.object_id) <> 'sys' go
Its nearly 4 times faster, & less code to write. Of course if you still want to filter for User Tables the OBJECT_ID() function will work as I showed in Example 1.
This approach is especially handy when working with Dynamic Management Views which I’ll show in a future post.
Hope this encourages you to read up on some of the other SQL System functions.
Thought for the Post
OMG (Oh! My God) is an expression that seems to be everywhere these days. But I wonder if I could read Arabic, do they type OMA (Oh! My Allah) or is the term God sufficiently generic? Will we start seeing OMB for those who follow Buddha. OMJ (Oh! My Jehovah), OMI (Oh! My Infinity) for the Scientologists. etc
If someone says “Oh! My” are they an Atheist or just too lazy to mention the omnipotent super-being of their choice.
I assume that an Antagonist would type OYG (Oh! your God!) or perhaps OME (Oh! My Ex-god).
It was so much easier when people used four letter words to express themselves.
So if you ever find yourself texting someone who you can see from where you are sitting. Or you say “LOL” instead of actually laughing. Be aware that most of the people around you including those your own age, probably think you are a <insert expletive here>.