#mysql #date #mariadb #query-performance
#mysql #Дата #mariadb #запрос-производительность
Вопрос:
При использовании MariaDB (MySQL) мы хотим превратить дату-ВРЕМЯ в читаемую ДАТУ и знать, по крайней мере, следующие методы, все из которых выдают одинаковый вывод даты, но … есть ли какие-либо фактические различия в производительности между этими преобразованиями, учитывая, что диалог будет отображаться в нескольких столбцах большого набора данных
DATE(NOW())
CAST(NOW() AS DATE)
DATE_FORMAT(NOW(), '%Y-%m-%d')
CONVERT(NOW(), DATE)
База данных находится на сетевом сервере, который используется другими пользователями, поэтому метод проб и ошибок не даст надежных результатов. Я не могу объяснить ничего, что пользователи используют в базе данных и / или любой другой сетевой / серверной активности, которая может происходить одновременно. Создание локальной копии обеспечило бы более (но не полностью) стабильный результат, но на наших копируемых устройствах мы не можем делать копии базы данных.
Вопрос конкретно направлен на различие между четырьмя вариантами и любыми другими, которые я, возможно, не рассматривал с точки зрения «есть ли какая-либо фактическая разница между ними»
Комментарии:
1. Протестируйте все эти параметры на большом наборе данных, и вы получите свой ответ!
2. База данных находится на сетевом сервере, который используется другими пользователями, поэтому метод проб и ошибок не даст надежных результатов. Я не могу объяснить ничего, что пользователи используют в базе данных и / или любой другой сетевой / серверной активности, которая может происходить одновременно.
3. создайте локальную копию таблицы и выполните тест в стабильной среде.
4. Извиняюсь, возможно, моему вопросу не хватает ясности; Я не ищу решение «методом проб и ошибок».
5. Ничто не мешает вам настроить локальный экземпляр при тестировании там
Ответ №1:
Использование подобных функций не окажет существенного влияния на производительность запроса, если они появятся в вашем SELECT предложении. Различия слишком малы, чтобы их можно было измерить: они составляют не более десятков наносекунд на строку. Используйте тот, который упрощает чтение вашего запроса следующему пользователю, и не оглядывайтесь назад.
DATE_FORMAT() однако выдает текстовую строку. Вам следует избегать этого, если вы не хотите контролировать точное форматирование вашей даты в отчете.
Если они отображаются в вашем WHERE предложении, они могут сделать невозможным использование MySQL индекса в столбце даты. Например, это повлияет на вашу производительность.
WHERE DATE(timestampcolumn) = DATE(NOW()) /* slow! */
Это медленно, потому что он должен оценивать DATE() функцию в каждой строке таблицы. То же самое относится и к другим соглашениям в вашем примере.
Если вы хотите выполнить такую фильтрацию, сделайте это вместо этого.
WHERE timestampcolumn >= DATE(NOW())
AND timestampcolumn < DATE(NOW()) INTERVAL 1 DAY
Если у вас включен индекс timestampcolumn , это WHERE предложение выполнит сканирование диапазона по этому индексу, экономя много работы на вашем сервере.
Комментарии:
1. Спасибо за конструктивный ответ; Я подозреваю, что ядро базы данных интерпретирует функции, и фактическое выполнение одинаково для каждого.
2. @ Sean это, безусловно, не так! Как было указано в ответе, date_format() выдает строку, а не дату, поэтому она должна иметь другое выполнение по сравнению со всеми другими перечисленными преобразованиями. Результаты могут выглядеть одинаково, но не совпадают!
Ответ №2:
Существенной разницы в производительности нет.
Но это должно быть быстрее, чем все упомянутые:
CURDATE()
(Если вам нужно что-то другое, кроме текущей даты, см. Ответ О. Джонса.)
Еще один момент: любое «постоянное» выражение будет вычисляться один раз для запроса, а не один раз для каждой строки. Это означает, что все значения NOW() or CURDATE() будут идентичны на протяжении всего запроса.
И это дополнительно указывает на неэффективность DATE(column) для большой таблицы.
Комментарии:
1. Но не все функции даты / времени являются постоянными, sysdate() всегда возвращает текущее время.
2. @Shadow — Да,
SYSDATE()это единственное недетерминированное исключение.