What is considered a “large” table in SQL Server?

Question

I have a table with 10 million records in it. Is that considered a lot of records? Should I be worried about search times? If not, it will keep growing, so what is cons

Answer 1

As Aaron said, it is relative. But maybe I can elaborate some.

First, one major factor is how large the columns are. If you have a table of nothing but 10 million integers (and there are reasons you just might want something like that, look at Tally Tables.) then it is not large at all. On the other hand, a denormalized table of merely a hundred rows might take up a lot of space and have massive performance problems if each row contained say an id field with an integer acting as a primary key followed by a varchar(max) with html and then a sequence of varbinary(max) columns that held jpgs used by that html.

So, to get a handle on the size of the table, you need to look at both the number of rows and the size of each row. One metric for size that might be a bit more useful is to look at the space it takes up. (Assuming this is later than SQL Server 2000, you can right click on the table in SSMS, go to properties, and then to the Storage page.)

Of course, its still hard to say when that will start affecting performance. You will certainly notice a change in performance once the table gets too large to fit inside of RAM, but that can happen frequently with decent sized datasets, especially if you choose to partially denormalize and is not a cause for concern. Having indexes that are too large to fit inside of RAM can cause a bigger performance concern, and that one can be cause for evaluation. But its not necessarily a problem, especially if it is meant to be a covering index for some query and you are working with a RAM constrained environment (what RAM constrained means is also relative, but for a rough rule of thumb there I would try to put at least 8 GB on even a desktop that was going to do serious work with SQL Server).

Now, table size certainly can be a factor in search speed and there are ways to deal with it. But before I talk about those, let me point out that it is normally one of the smaller factors I would look at in terms of performance. I wrote an article about this recently here. Before thinking about table size, I would look to make sure the queries were optimized, and the indexes made sense. I would even look at increasing RAM and getting faster harddrives (SSDs make a difference if you can afford one large enough for your purposes) before worrying about table sizes.

But, if you want to decrease table size:

• Normalize. This can actually have some big drawbacks for performance, but it can have some performance advantages and it has big data consistency advantages as well as storage advantages.
• Consider your datatypes. If you need NVarchar, you need NVarchar. But if varchar will work, then it will use up less space. Same with int vs bigint.
• Partition. Again, done wrong this can degrade performance instead of improving it, but done right it can help with performance. It can be somewhat tricky to do right so approach with caution.
• Move old, unnecessary data to an archival warehouse and out of the main system. Of course, this depends on getting the definition of unnecessary data right.

Summary:

This got longer than I expected, so to summarize:

1. What is large is relative, but you have to consider the column size along with the number of rows.
2. The table size can definitely affect performance, but lots of other things affect it more, so I wouldn't look there first or even second.
3. If you must reduce table size, basically get rid of data you don't need, and reallocate other data to other places. But you have to be smart about how or you can do more harm than good.