A media company stores video metadata in Amazon Aurora MySQL. The application performs frequent range queries on a 'creation_date' column. The table has 10 million rows. The team notices that queries filtering on 'creation_date' are slow despite an index on that column. The query pattern is: SELECT * FROM videos WHERE creation_date BETWEEN '2023-01-01' AND '2023-01-31' ORDER BY creation_date LIMIT 100. The execution plan shows a full index scan. What is the MOST likely cause?
SELECT * forces the database to fetch full rows; a covering index could avoid that.
Why this answer
The query uses SELECT *, which forces the database engine to retrieve all columns from the table. Even though the index on creation_date is used for sorting and filtering, the query optimizer may choose a full index scan because it still needs to access the table rows for the non-indexed columns. This is often more efficient than random lookups for a large range, but it still results in scanning many index entries and performing table lookups, causing the observed slowness.
Exam trap
The trap here is that candidates assume an index is not being used (Option C) when the execution plan shows a full index scan, but the real issue is the overhead of retrieving all columns from the table, which is a common performance pitfall with SELECT * queries.
How to eliminate wrong answers
Option A is wrong because a composite index on (creation_date, id) would not significantly improve this query; the query already uses the creation_date index for range filtering, and adding id does not reduce the need to access the table for other columns. Option B is wrong because partitioning by creation_date could help with partition pruning, but the question states the index is already being used (full index scan), and the slowness is due to table access, not partition elimination. Option C is wrong because the execution plan explicitly shows a full index scan, meaning the index on creation_date is being used; the problem is not index non-use but the overhead of fetching all columns from the table.