timestamp - Выборка по "like" и по ">"

Роберт

Аналитик
timestamp - Выборка по "like" и по ">"

У меня MySQL 5.0.15
Таблица с немного более чем миллионом записей.
CREATE TABLE `QuerysLog` (
`Id` int(10) unsigned NOT NULL auto_increment,
`UserLogin` varchar(20) default NULL,
`UserIP` varchar(15) default NULL,
`QueryText` varchar(50) default NULL,
`QueryTime` timestamp NOT NULL,
PRIMARY KEY (`Id`),
KEY `QueryTime` (`QueryTime`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;
Тоесть в ней несколько текстовых полей и проиндексированное TimeStamp поле.
Вопрос именно по timestamp'у.

Если я делю выборку:
select * from QuerysLog where QueryTime > '2005-11-04'
это занимает 0.03 секунды (в выборке всего пара тысячь записей).

А если запрашиваю:
select * from QuerysLog where QueryTime like '2005-11-04%'
то время запроса 0.90 (почти секунда).

Сразу скажу , что кеширования на базе отключено.

Если запрошу:
... QueryTime > '2005-11-04' and QueryTime < '2005-11-05'
тоже 0.03 секунды.

А запрос:
... QueryTime like '_005-11-04%'
занимает 0.90 секунды (в 30 раз больше чем через ">" и "<")

Я понимаю что для like '_005-11-04%' нужно перелистать всю таблицу , так как первый символ неизвестен и индексы использовать нельзя. Но почему для like '2005-11-04%' не используются индексы??? Ведь первая часть известна и можно найти запись по бинарному дереву точно так же как это делается при запросе QueryTime > '2005-11-04'. И даже при фулъиндексе поиск по '2005-11-04*' использует индексы.
Почему like '2005-11-04%' тормозит?
 

Profic

just Profic (PHP5 BetaTeam)
Потому что индекс не текстовый, а операция текстовая => для каждой нужно сконвертироать значение в строку и проверить подходит ли она под маку => индекс на помойку, только голый fullscan.
 

Роберт

Аналитик
Хм... Действительно всё именно так...
Я вначале думал что раз в кавычках - то ищит как текст. Даже подставлял нереальные строки времени типа '2005-11-04 ' или '2005-11-04 2'. Но после твоей подстказки попробывал ввести:
QueryTime > '2005-11-04 23'
и
QueryTime > '2005-11-04 25'

И действительно - в первом случае поиск за 0.03 секунды , а во втором за 0.90 секунды. Что означает что он мою первую строку конвертнул во время (дата и 23 часа) , а во втором случае строку оставил как есть и начал конвертировать каждую дату в таблице в строку и сравнивать с моей строкой (так как 25-того часа не существует).
 
Сверху