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 considered a large table? How much does table size factor into search time, and what can I do to ameliorate those issues, preferably before they become issues?

Answer 1

"Large" is like "smart" - it's relative. 10 million rows is a good size, but whether the table is large depends on a number of factors:

• how many columns and what are their data types?
• how many indexes?
• what is the actual size of the table (e.g. number of pages * 8kb, which you can get from sys.dm_db_partition_stats)?
• what type of queries are run against it?
• are individual indexes held in memory or do most queries benefit from a clustered index scan (where, essentially, the whole table needs to be in memory)?
• how much memory is on the machine?
• what do you consider large?

Search times are not necessarily driven by size per se, but rather the effectiveness of your indexing strategy and the types of queries you're running for searches. If you have things like:

WHERE description LIKE '%foo%' 

Then a normal index is not going to help you whatsoever, and you should start to get worried. You might consider Full-Text Search for cases like this.

10 million rows in a table with a single INT column (e.g. a Numbers table) is nothing. 10 million rows of Products with long descriptions, XML, Geography data, images etc. is quite another.

There is a reason that the max capacity specifications for SQL Server do not document an upper bound for number of rows in a table.