I have 30 millions records and one field (updated) is a tinyint(1) with an index.
If I run:
SELECT * FROM `table` WHERE `updated` = 1
It will take an increasingly long time depending on how many are set to 1.
If it is say 10,000 it will be quite fast about 1 second. However if there is say 1 million it takes a couple of minutes.
Isn’t the index suppose to make this fast?
When I run the same query on a non-indexed field that is similar only it is int(1) it performs the same as the indexed field.
Any ideas as to why this would be? is tinyint bad?
In general, using a binary column for an index is not considered a good idea. There are some cases where it is okay, but this is generally suspect.
The main purpose of an index is to reduce the I/O of a query. The way your query is expressed, it requires both the original data (to satisfy “select *”) and the index (for the where clause).
So, the database engine will go through the index. Each time it finds a matching record, it brings the page into member. You have an I/O hit. Because your table is so large, the page probably was not seen already, so there is a real I/O hit.
Interestingly, your experience supports this. 10,000 rows is about one second. 100 times as many rows (one million) is about 100 seconds. You are witnessing linearity in performance.
By the way, the query would be faster if you did “select update” instead of “select *”. This query could be satisfied only from the index. If you have an id column, you could create the index on (update, id), and then do “select id” for performance.