# Avoided filesort, but more rows to exmaine, need advice!

**URL:** <https://forums.percona.com/t/avoided-filesort-but-more-rows-to-exmaine-need-advice/1010>\
**Category:** Other MySQL® Questions\
**Created:** [November 26, 2008, 4:24pm UTC](https://forums.percona.com/t/avoided-filesort-but-more-rows-to-exmaine-need-advice/1010 "2008-11-26T16:24:53Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![matthew016](https://avatars.discourse-cdn.com/v4/letter/m/5fc32e/32.png) [@matthew016](https://forums.percona.com/u/matthew016)\
**Post date:** [November 26, 2008, 4:24pm UTC](https://forums.percona.com/t/avoided-filesort-but-more-rows-to-exmaine-need-advice/1010/1 "2008-11-26T16:24:53Z")

</div>

Hi,

I am pretty new in optimizing tables with index and may need some help.  
This is my query:

EXPLAIN SELECT timestamp  
FROM Meting\_INT\_COPY  
WHERE blockid = ‘200811252000’  
ORDER BY timestamp DESC  
LIMIT 1

If I have an index(blockid),  
EXPLAIN will return the following information:

type possible\_keys key rows Extra  
ref index\_blockid index\_blockid 2638 Using where; Using filesort

If I add an index(blockid,timestamp)  
EXPLAIN will display the following:

type possible\_keys key  
rows Extra  
ref index\_blockid,index\_blockid\_timestamp index\_blockid\_timestamp 8248  
Using where; Using index

The index(blockid,timestamp) avoid the filesort + returns the result from index ! (Using where; Using index)  
But why for the index(blockid) 2638 rows are returned to examine and for a more  
specific index(blockid,timestamp) 8248 rows are returned ?

Thank you very much for any answer !

---

<div class="post-metadata">

**Author:** ![MarkRose](https://avatars.discourse-cdn.com/v4/letter/m/85f322/32.png) [@MarkRose](https://forums.percona.com/u/MarkRose)\
**Post date:** [March 21, 2009, 7:48pm UTC](https://forums.percona.com/t/avoided-filesort-but-more-rows-to-exmaine-need-advice/1010/2 "2009-03-21T19:48:31Z")

</div>

If you run the query without the LIMIT 1 at the end, I bet you would see more row examined without the additional index. It just so happens that the non-indexed execution is stumbling upon a matching row early into its search.
