Запрос должен забирать все строки ровно за одни или несколько суток? Не уверен, что сильно поможет, можно для этой цели попробовать добавить в таблицу числовое поле с обозначением только даты и проиндексировать его.
Вообще, мало исходных данных. Какой движок использует таблица, каков её размер, висит ли она в памяти целиком или всякий раз с диска читается.

OnausesЗапросы разные. По суткам, неделям, может месяцам.Кратны ли периоды выборки целым суткам от нуля часов до без секунды полночь? Если нет (имеются значения времени, отличные от 00:00:00 и 23:59:59), то и нет смысла смотреть в эту сторону. Смысл тут в отдельном, небольшом индексе для даты.

OnausesДвижок MariaDBНичего не путаете? Это СУБД есть такая. Список поддерживаемых в ней движков: https://mariadb.com/kb/en/mariadb/storage-engines/
Скорее всего, MyISAM или InnoDB.

OnausesИзвините, InnoDB.InnoDB умеет держать всю таблицу в оперативной памяти. Конечно, только в том случае, когда этой самой памяти достаточно.
Вы упоминали, что база (или Вы имели в виду таблицу?) целиком имеет объем больше, чем имеется памяти на сервере. В таком случае база целиком гарантировано не лезет в память и неиспользуемые данные будут со временем вымываться из памяти. Соответственно, вполне вероятно что при относительно редких запросах диску придется всякий раз шуршать головками, читая необходимые данные с диска. А это операция медленная.

miksoftТогда так:

Различия есть, но чем оно принципиально лучше/хуже запроса из первого поста?
OnausesSELECT * FROM sessions WHERE loginID="1" AND date BETWEEN STR_TO_DATE('2016-05-23 00:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2016-05-23 23:59:59', '%Y-%m-%d %H:%i:%s')

miksoftНо лучше читается, более корректно обращается с последней секундой суток (на случай, если дата будет содержать дробные секунды)Однозначно, согласен.


miksoftвозможно, указание явных констант без вызова функций облегчит жизнь оптимизатору при оценке кардинальности результата (но это совсем не точно).Вот тут я не владею в достаточной степени тонкостями внутренней кухни мускуля. Если где ошибаюсь - поправьте сразу, пожалуйста.
Предположу, что вариант ТС выполнит однократное явное преобразование строки во внутреннее представление даты. Ну а далее выполняется сравнение данных одного типа. С этим как-то ясно-понятно. Ваш вариант, врзможно, потребует какого-то принятия решения о неявном преобразовании "что во что конвертить" перед сравнением и, затем, наверняка, будет выбрано преобразование строки в дату и далее уже как и в варианте ТС. Вот тут конечный результат подготовки тоже одинаковым выходит.
Так вот, если отбросить человеческий фактор "лучше читается" и способ задания границ выборки, но оставить лишь рассмотрение с машинной точки зрения, если так можно выразиться, то можно, полагаю, считать вариант ТС более удобным. Или же, это всё такие мелочи, на которые можно не обращать внимания?