Comments on: Performance Considerations of Data Types http://sqlfool.com/2009/05/performance-considerations-of-data-types/ Adventures in SQL Tuning - a blog for the rest of us Tue, 07 Feb 2012 21:28:07 -0700 hourly 1 http://wordpress.org/?v=3.0 By: Another Super Bowl, Another 27k TPS « SQL Fool http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-5630 Another Super Bowl, Another 27k TPS « SQL Fool Wed, 16 Feb 2011 16:01:12 +0000 http://sqlfool.com/?p=951#comment-5630 [...] Twitter, you'll know that I'm big on performance tuning, from the bottom up. That means things like good table design, effective clustered indexing, and taking advantage of new features like filtered indexes. These [...] [...] Twitter, you'll know that I'm big on performance tuning, from the bottom up. That means things like good table design, effective clustered indexing, and taking advantage of new features like filtered indexes. These [...]

]]> By: Michelle Ufford http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-4932 Michelle Ufford Thu, 10 Sep 2009 14:09:41 +0000 http://sqlfool.com/?p=951#comment-4932 @Stephen You can find the article directly using this URL: http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf @Stephen You can find the article directly using this URL:
http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

]]> By: Stephen http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-4927 Stephen Wed, 09 Sep 2009 14:17:13 +0000 http://sqlfool.com/?p=951#comment-4927 I can't find this article on the SQL Pass site, it seems they reorg'd the site. Is there another place I can find this article? I can’t find this article on the SQL Pass site, it seems they reorg’d the site. Is there another place I can find this article?

]]> By: Overhead in Non-Unique Clustered Indexes : SQL Fool http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3838 Overhead in Non-Unique Clustered Indexes : SQL Fool Thu, 21 May 2009 13:22:33 +0000 http://sqlfool.com/?p=951#comment-3838 [...] received a couple of questions regarding my article, Performance Considerations of Data Types, and the overhead associated with non-unique clustered indexes. I started to respond via e-mail, [...] [...] received a couple of questions regarding my article, Performance Considerations of Data Types, and the overhead associated with non-unique clustered indexes. I started to respond via e-mail, [...]

]]> By: Michelle Ufford http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3798 Michelle Ufford Wed, 20 May 2009 13:36:51 +0000 http://sqlfool.com/?p=951#comment-3798 @David Thanks! I'm going to write a blog post about this to help clarify a little bit what's happening. Basically, your searches would perform faster if you're clustering on date and searching on date, but yes, there's overhead in terms of the space used to store the clustered index. And because your clustering key is also stored in your non-clustered keys, that overhead is felt in every other index, too. This isn't such a big deal in smaller tables, and it's not necessarily a bad thing anyway. Every environment and every application is different, so it's impossible to say more without knowing your specifics. Are you OLTP, DSS, OLAP? What's more important, fast reads or fast writes? All of this is important to consider and makes a difference when choosing a clustering key. The point my article was making is really that performance can, in general, be improved by using an unique clustered key. I hope that helps clarify, and like I said, I'm working on a blog post to help clarify things further. Thanks for the comment! :) @David Thanks! I’m going to write a blog post about this to help clarify a little bit what’s happening. Basically, your searches would perform faster if you’re clustering on date and searching on date, but yes, there’s overhead in terms of the space used to store the clustered index. And because your clustering key is also stored in your non-clustered keys, that overhead is felt in every other index, too. This isn’t such a big deal in smaller tables, and it’s not necessarily a bad thing anyway. Every environment and every application is different, so it’s impossible to say more without knowing your specifics. Are you OLTP, DSS, OLAP? What’s more important, fast reads or fast writes? All of this is important to consider and makes a difference when choosing a clustering key. The point my article was making is really that performance can, in general, be improved by using an unique clustered key.

I hope that helps clarify, and like I said, I’m working on a blog post to help clarify things further. Thanks for the comment! :)

]]> By: Michelle Ufford http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3797 Michelle Ufford Wed, 20 May 2009 13:29:59 +0000 http://sqlfool.com/?p=951#comment-3797 @Caleb thanks! Yes, you're exactly right about NEWSEQUENTIALID(), but one of the most prevalent reasons to use GUIDs appears to be the fact that they're generated in the .NET tier and then passed to SQL Server. So although I work with many applications that store UNIQUEIDENTIFIERS, I've never once had the occasion to actually use NEWSEQUENTIALID(). That may not be true in other environments, though, but has been my experience. Thanks for the comment! :) @Caleb thanks! Yes, you’re exactly right about NEWSEQUENTIALID(), but one of the most prevalent reasons to use GUIDs appears to be the fact that they’re generated in the .NET tier and then passed to SQL Server. So although I work with many applications that store UNIQUEIDENTIFIERS, I’ve never once had the occasion to actually use NEWSEQUENTIALID(). That may not be true in other environments, though, but has been my experience. Thanks for the comment! :)

]]> By: David Hay http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3740 David Hay Mon, 18 May 2009 13:24:40 +0000 http://sqlfool.com/?p=951#comment-3740 Great article! I'm having a bit of a problem understanding the non unique clusterd index portion though, particularly about dates. "However, creating a non-unique clustered index on a column with many duplicate values, perhaps on a column of date data type where you might have thousands of records with the same clustered key value, could result in a significant amount of internal overhead." We have sales data that we mainly query by date or date range, by putting the clustered index over the date column that has significantly increased the performance of the related queries. Is the overhead only in space used, or is there more to consider that I am missing? Great article! I’m having a bit of a problem understanding the non unique clusterd index portion though, particularly about dates.

“However, creating a non-unique clustered index on a column with many duplicate values, perhaps on a column of date data type where you might have thousands of records with the same clustered key value, could result in a significant amount of internal overhead.”

We have sales data that we mainly query by date or date range, by putting the clustered index over the date column that has significantly increased the performance of the related queries. Is the overhead only in space used, or is there more to consider that I am missing?

]]> By: SQL Server and Cloud Links for the Week | Brent Ozar - SQL Server DBA http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3630 SQL Server and Cloud Links for the Week | Brent Ozar - SQL Server DBA Fri, 15 May 2009 13:07:59 +0000 http://sqlfool.com/?p=951#comment-3630 [...] Why you gotta use the right field types - if you’re only storing 10 characters of data, you don’t need a 50-character bag.  The bigger the bag, the more the bag weighs, and your SQL Server slows down because it’s gotta carry all these big bags.  Michelle Ufford explains (with much more accurate language) how this affects your SQL Server performance. [...] [...] Why you gotta use the right field types – if you’re only storing 10 characters of data, you don’t need a 50-character bag.  The bigger the bag, the more the bag weighs, and your SQL Server slows down because it’s gotta carry all these big bags.  Michelle Ufford explains (with much more accurate language) how this affects your SQL Server performance. [...]

]]> By: Caleb Benefiel http://sqlfool.com/2009/05/performance-considerations-of-data-types/comment-page-1/#comment-3568 Caleb Benefiel Wed, 13 May 2009 20:45:08 +0000 http://sqlfool.com/?p=951#comment-3568 Great article! One note regarding clustered indexes on uniqueidentifiers: "Uniqueidentifiers are an expensive pointer because they are typically not sequential and because they consume 16 bytes. One environment in which I’ve worked contained two tables, each with over a billion rows, clustered on a non-sequential uniqueidentifier, and 99.998% fragmented." I have run into similar situations. Depending on how and where the GUID is being generated, NEWSEQUENTIALID() can be a great alternative to refactoring the database. http://msdn.microsoft.com/en-us/library/ms189786.aspx You still have the 16 byte vs 8 byte consideration, but the fragmentation problem is largely mitigated. Caleb Great article! One note regarding clustered indexes on uniqueidentifiers:

“Uniqueidentifiers are an expensive pointer because they are typically not sequential and because they consume 16 bytes. One environment in which I’ve worked contained two tables, each with over a billion rows, clustered on a non-sequential uniqueidentifier, and 99.998% fragmented.”

I have run into similar situations. Depending on how and where the GUID is being generated, NEWSEQUENTIALID() can be a great alternative to refactoring the database. http://msdn.microsoft.com/en-us/library/ms189786.aspx You still have the 16 byte vs 8 byte consideration, but the fragmentation problem is largely mitigated.

Caleb

]]>