We help IT Professionals succeed at work.

INDEXING with Cast / Convert function in SQL Server (Enhancing Query Performance)

Last Modified: 2014-02-10
I have several SQL Server tables which are dropped and reloaded through text files on a regular basis. The result is dozens of tables which all have the data type NVARCHAR(255). In the past this has worked fine since I can cast the data type to whatever I want later without having to worry about type conversion issue on the daily job. This practice has now created an issue since I would like to create an index on a datetime derived field that is stored as a multiple text fields. Is it possible to create an index on a value that is derived from the table? In my case I would like something similar to:

ON [dbo].[Position_Dta]
([Position Number - Position Dta],
DATEADD(Minute, cast([Effective Date Sequence # - Position Dta] as int), [Effective Date - Position Dta]),
cast(tbl_Secondary.[Action Date - Position Dta] as date))

Obviously the above syntax does not work but hopefully that helps explain what I am looking for. Essentially the query I have in the example is one of dozens of subqueries with the same issue and the result is queries that take 4 hours to run. I suppose I would create a temp table with the correct data types and index the temp table but I was really hoping for a solution that would not cause me to have to update a lot of functioning code (even though it is super slow it works). Additionally I am not the only person who accesses these tables so I am really trying to avoid modifying the source tables.

Attached is a copy of a typical example where I am trying to create a more effective index.  I am open to any ideas that will increase performance and the less modification to the existing code the better! I appreciate the help experts!
Watch Question

You can add computed columns to the tables and then make the index on those.

Here is a topic about computed columns: http://technet.microsoft.com/en-us/library/ms191250(v=sql.105).aspx
And here about indexes on them: http://technet.microsoft.com/en-us/library/ms189292.aspx

To create an index on TWO tables as you showed in the question is not good solution probably...

You should try to create index on  [Position Number - Position Dta]  column on both tables and see what happens. Then you may add indexes on [Effective Date Sequence # - Position Dta] and [Effective Date - Position Dta] which will optimize your subquery.

The "less than comparison part" of the WHERE condition isn't easily optimizable and the index on computed column could be a good start BUT I am skeptic...


Sorry, the screen shot is not 100% accurate. All the data is coming from the same table. So the table alias tbl_Primary and tbl_Secondary are actually the exact same table.

In such case I would rather create a temporary table which will be used in place of the first subselect. This subselect must slow down the whole query because it calculates minimum from unoptimized data.

So create a table where each  [Position Number - Position Dta]  value has one corresponding value calculated as MIN(DateAdd(MINUTE, ...  WHERE ... etc.
and join this table by LEFT JOIN to your Position_dta table. This should optimize the subselect part.

If the result will be still slow then you may optimize the correlated subquery in the WHERE part.
What about the computed columns I wrote about?


The computed columns looks promising but it would seemingly require me to rewrite much of my code. I am going to try a small test with the concept and test the performance gains.
SQL Server Data Dude
Most Valuable Expert 2013
Author of the Year 2015
This one is on us!
(Get your first solution completely free - no credit card required)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.