Есть таблица с полем типа DATE. Нужно выбирать строки по нему. Есть два запроса с одинаковым результатом:

и


По сему вопрос: какой из этих запросов производительнее?

второй. кавычки вокруг чисолвых констант можно убрать.
------
логика первого: поле(значение поля) приводится к строковому типу, по которому производится поиск с использованием шаблонов(среди строковых функций медленнее like только regexp).
логика второго: вычленяется целочисленное значение из целочисленного значения(видимо, при помощи простых арифметических операций). даже с приведением результата к строковому типу(так как у тебя константы - строковые) все равно должно получаться много быстрее первого варианта. но ключи не используются.
------
мне думается, вариант, использующий возможный ключ по полю `date`, должен выглядеть так:

Дело в том, что мне нужно извлекать даты исходя из поступивших значений значения месяца и года. С первым числом месяца проблем не возникнет:

Но вот если пихать последним 31:

То может возникнуть абсурд типа 2007-02-31, что будет в таком случае - я не знаю.

Это сообщение отредактировал(а) Sunvas - 29.8.2008, 21:19

зачем тебе последний день месяца? 

Чтобы выбрать все строки из таблицы с датой этого месяца и не важно, каким днем.

я приводил пример. в нем выбираются все записи для "даты конкретного месяца с неважно каким днем". покажи мне, где там используется последний день месяца.

А может проще date_format?

Nigel, вместо работы с целыми числами - преобразование в строку? кхм, к первоначальному вопросу про "запрос производительнее".

skyboy, в Вашем примере нужно увеличивать значение месяца на 1. А для этого нужно парсить входящую строку...

ну, так используй второй вариант.

уже входящая строка какая-то. я-то думал, что мы говорим про SQL, который кто-то где-то генерирует...

Ищу варианты, чтобы все сделать максимально производительно. Кстати о каком втором варианте Вы говорите?

второй вариант. кстати говоря, раз уж тут отдельно - месяц и год, то и в этом случае придется парсить строку.
но при большом количестве строк этот "единоразовый парсинг" будет незаметен на фоне выигрыша при использовании индекса по целочисленному полю(вариант "`date`>= '01-05-2007' AND `date`< '01-06-2007'") или при работе с числами вместо строк(WHERE MONTH(`date`)='5' AND YEAR(`date`)='2007').

skyboy, и? При условии date<=/date>= все-равно будет идти сравнение строк. У автора дата же не в виде числа хранится

мне казалось, что если дата хранится как положено - в datetime, то константа будет преобразована из строковой формы в числовую один раз. и потом будет использоваться возможный индекс на поле с датой...

Добавлено через 11 минут и 48 секунд
проводим эксперимент:

имеем одну запись. после чего выполняем запрос

несколько раз(я выполнил его 20 раз и получил, закономерно, 1048576 записей).
после чего выполняем:

наблюдаем:

т.е. индекс работает.
пробуем по-другому:

картина меняется незначительно:

индекс используется все равно.
пробуем вариант с like:

К моему удивлению, индекс используется все равно:

по всей видимости, оптимизатор умнее меня 
вывод: по вопросам производительности лучше не искать совета со стороны, а самостоятельно провести полевые испытания.

Добавлено через 12 минут и 52 секунды

datetime - это число. то, что оно возвращается отформатированным в виде строки, не значит, что там и хранится строка.

Тип date хранится как число дней(целый тип), прошедших с определенной даты. У разных СУБД эта стартовая дата может быть разная. Соответственно индекс по типу date сильно помогает в запросах.