Question

I’ve got a table which is growing slowly, call people
currently there are 50,000 records and it gains about 5000 a month.

It was written by someone (not me!)
who didn’t add any indexes,
and there are numerous queries that use non-pk where clauses.

For example:

select * from people where email = '[e-mail]';

According to the mysql command line client, this executes in “0” time …

1 row in set (0.00 sec)

I also tried, in an attempt to make a slower query:

# attempt!
select * from people where email like 'Name%';

# result
23 rows in set (0.00 sec)

My understanding is a query like this does a full table scan.
So if a full table scan of 50,000 rows takes less then 1/100th of a second,
at what point does it actually get slower?

Answer 1

With 50,000 records it probably makes sense to create an index to help with queries (or possibly more than one index depending on the queries and how often they are run). And with only 5,000 records being added each month, the maintenance of the index (assuming not a lot of other updates) shouldn’t be very costly.

I do not know how accurate the timer is for those results but it seems within the realm of possibility for a full table scan to occur in less than 1/100 of a second (depending on how aggressive the caching is and how big the physical record size is). I just now ran a query on my own development PC (with a completely different database engine) that did a full table scan of 40,000 records in .013 seconds. And my dev PC isn’t anything special.

(I didn’t have a 50,000 record table handy in a MySQL database, but I did have the 40,000 record one immediately available for a different database. So the comparison may not be exactly comparable, but it probably isn’t completely out to lunch.)