Запрос не использует индекс

[AHTIXPICT]

Запрос не использует индекс

Есть такая таблица
[sql]
CREATE TABLE `prtn_results_total` (
`uid` int(10) unsigned NOT NULL default '0',
`s_id` int(10) unsigned NOT NULL default '0',
`r_date` date NOT NULL default '0000-00-00',
`r_ravs` mediumint(5) unsigned NOT NULL default '0',
`uniq` mediumint(8) unsigned NOT NULL default '0',
`r_tb` mediumint(5) unsigned NOT NULL default '0',
`r_smstrue` smallint(5) unsigned NOT NULL default '0',
`r_smsrebil` smallint(5) unsigned NOT NULL default '0',
`r_summ` decimal(17,2) NOT NULL default '0.00',
`r_summref` decimal(17,2) NOT NULL default '0.00',
PRIMARY KEY (`uid`,`s_id`,`r_date`),
KEY `r_sms_idx` (`r_smstrue`,`r_smsrebil`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
[/sql]

Там сейчас прмерно 17к записей

Делаю такой запрос

[sql]
EXPLAIN SELECT
r_date,
sum(r_ravs) as r_ravs,
sum(uniq) as uniq,
sum(r_tb) as tb,
sum(r_smstrue) as smstrue,
sum(r_smsrebil) as smsrebil,
sum(r_summ) as summ,
sum(r_summref) as summref
FROM prtn_results_total
WHERE (r_date BETWEEN '2008-10-01' AND '2008-10-15')
GROUP BY r_date
ORDER BY r_date
[/sql]

получаю
+----+-------------+--------------------+--------+---------------+--------+---------+--------+--------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------------------+--------+---------------+--------+---------+--------+--------+----------------------------------------------+
| 1 | SIMPLE | prtn_results_total | ALL | [NULL] | [NULL] | [NULL] | [NULL] | 17207 | Using where; Using temporary; Using filesort |
+----+-------------+--------------------+--------+---------------+--------+---------+--------+--------+----------------------------------------------+

Не пойму почему не используется примари-кей
В тоже время если делать такой же запрос но еще и "AND (uid=355)" например
тогда все нормально
[sql]
EXPLAIN SELECT
r_date,
sum(r_ravs) as r_ravs,
sum(uniq) as uniq,
sum(r_tb) as tb,
sum(r_smstrue) as smstrue,
sum(r_smsrebil) as smsrebil,
sum(r_summ) as summ,
sum(r_summref) as summref
FROM prtn_results_total
WHERE (r_date BETWEEN '2008-10-01' AND '2008-10-15')
AND (uid=355)
GROUP BY r_date
ORDER BY r_date
[/sql]
+----+-------------+--------------------+--------+---------------+---------+---------+--------+--------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------------------+--------+---------------+---------+---------+--------+--------+----------------------------------------------+
| 1 | SIMPLE | prtn_results_total | ref | PRIMARY | PRIMARY | 4 | const | 264 | Using where; Using temporary; Using filesort |
+----+-------------+--------------------+--------+---------------+---------+---------+--------+--------+----------------------------------------------+

 

[HraKK]

AHTIXPICT
А с какого фига там должен быть поиск по примари индексу?!!

 

[флоппик]

Для использования многоколоночного ПК нужно задействовать в запросе все учавствующие столбцы в ПК.

 

[AHTIXPICT]

HraKK А более информативно ты можешь ответить.

флоппик
http://dev.mysql.com/doc/refman/5.1/en/create-table.html
Где ты такое вычитал
------
A PRIMARY KEY is a unique index where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, MySQL declares them so implicitly (and silently). A table can have only one PRIMARY KEY. If you do not have a PRIMARY KEY and an application asks for the PRIMARY KEY in your tables, MySQL returns the first UNIQUE index that has no NULL columns as the PRIMARY KEY.
-----
флоппик
успел отредактировать свой ответ, теперь вышенаписанное мной немного не совсем праильное выражение.
Отредактированный ответ более менее похож на правду, хотя я еще не нашел этого в мануале, но опытным путем проверено, что если создать дополнительно индекс на поле r_date
[sql]
CREATE TABLE `prtn_results_total` (
`uid` int(10) unsigned NOT NULL default '0',
`s_id` int(10) unsigned NOT NULL default '0',
`r_date` date NOT NULL default '0000-00-00',
`r_ravs` mediumint(8) unsigned NOT NULL default '0',
`uniq` mediumint(8) unsigned NOT NULL default '0',
`r_tb` mediumint(8) unsigned NOT NULL default '0',
`r_smstrue` smallint(5) unsigned NOT NULL default '0',
`r_smsrebil` smallint(5) unsigned NOT NULL default '0',
`r_summ` decimal(17,2) NOT NULL default '0.00',
`r_summref` decimal(17,2) NOT NULL default '0.00',
PRIMARY KEY (`uid`,`s_id`,`r_date`),
KEY `uid_idx` (`uid`),
KEY `s_id_idx` (`s_id`),
KEY `r_sms_idx` (`r_smstrue`,`r_smsrebil`),
KEY `r_date_idx` (`r_date`)
[/sql]
то этот индекс используется, но используется только при определенном результируещем кол-ве записей.
Если кол-во найденых записей больше НЕИЗВЕСТНОГО (примерно > 3000) мне значения индекс снова не используется

 

[флоппик]

AHTIXPICT, угу. Я сам перечитал, и понял, что ошибся.

-~{}~ 11.10.08 18:43:

Если кол-во найденых записей больше НЕИЗВЕСТНОГО (примерно > 3000) мне значения индекс снова не используется

ЕМНИП, если количество выбираемых строк больше половины записей в таблице(точной цифры, или процентного отношения не знаю) то оптимизатор считает, что проще пробежаться по всей таблице, чем по индексу. Можно побороть через FORCE INDEX