Using Where during Explain for MySQL Query - mysql

Question

I have a table when making a query,
EXPLAIN SELECT `id`
FROM `tblsender`
WHERE `userid` = '6'
AND `astatus` = '1'
AND `sender` = 'ABCDEF'
I am getting USING WHERE even after indexing in all possible ways. Here is my final table structure code.
CREATE TABLE IF NOT EXISTS `tblsender` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`sender` varchar(6) NOT NULL,
`astatus` tinyint(1) NOT NULL DEFAULT '0',
`userid` int(11) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `astatus` (`astatus`),
KEY `userid` (`userid`),
KEY `sender` (`sender`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=22975 ;
I even tried full text for sender column but still no luck and I also tried indexing on all where clause columns.
ALTER TABLE `tblsender` ADD INDEX ( `sender` , `astatus` , `userid` ) ;
Still getting using where, how can I properly index this table.
Edit: Explain output for above structure.
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tblsender ref astatus,userid,sender astatus 1 const 1 Using where
and Explain output for all 3 columns together
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tblsender ref astatus,userid,sender,sender_2 astatus 1 const 1 Using where

Answer 1

You can't effectively predict optimizer behavior on large data sets when testing with small data sets.
As illustrated by the query plans, the multi column index is seen as a candidate, but the optimizer is choosing not to use it in this case. That doesn't mean it won't use it when it will be considered more beneficial.
I can only speculate without seeing your actual data set and perhaps using optimizer tracing, but I'll offer a reasonable speculation.
The optimizer in MySQL is cost-based. It tries to resolve your query in the least costly way possible. Note that rows = 1. This means that the optimizer has concluded that -- statistically, at least -- it expects that only 1 row is going to match in the index on astatus. With key_len = 1, meaning that astatus is only 1 byte wide -- as opposed to the multicolumn index, which is 11 bytes wide (1 + 6 + 4) -- the astatus index looks like a really inexpensive solution, so it decides to go with that index. Using the longer index theoretically means more I/O, therefore more costly, though in this case (because of a small data set) we humans recognize that the cost difference isn't particularly meaningful.
Using where means that for each row actually returned by using that index, the server will need to verify that the rows match the remainder of the WHERE clause, but if we're only expecting approximately 1 row to match, it's no big deal.
I suggest, then, that you do not have cause for concern, because the small size of the current data set is not going to be able to give you useful information in predicting future behavior. In this specific case, Using where is an artifact of the small number of rows in the table.
You need more data. But yes, you do want a multicolumn index here.