Лучший способ обработать дату MySQL для производительности с тысячами пользователей - PullRequest
2 голосов
/ 24 мая 2010

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

Должны ли мы хранить поле datetime как mysql datetime. Или следует разбить его на несколько полей (год, месяц, день, час, минута, ...)

Вопрос в том, что с большим набором данных и потенциально большим набором пользователей мы бы выиграли с точки зрения производительности, разбив дату и время на несколько полей и сэкономив на использовании функций даты в mysql? Или mysql уже оптимизирован для этого?

Ответы [ 3 ]

1 голос
/ 24 мая 2010

Ознакомьтесь с документацией MySQL Date & Time Functions , потому что вы можете извлечь конкретную информацию из даты, используя существующие функции, такие как YEAR , MONTH ,и т.д. Но, хотя они существуют, если у вас есть индекс для столбца (-ов) даты, использование этих функций означает, что эти индексы не могут быть использованы ...

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

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

0 голосов
/ 24 мая 2010

Если вы заранее знаете некоторые ключевые критерии, которые будут иметь все поиски, MySQL (> = v5.1) разбиение таблицы может помочь.

Например, если у вас есть такая таблица:

create table Books(pubDate dateTime, title varchar(50));

И вы знаете, что во всех поисках должен быть хотя бы один год, вы можете разбить его на поле даты следующим образом:

create table Books(pubDate dateTime,title varchar(50)  
partition by hash(year(pubDate)) partitions 10;

Затем, когда вы запускаете выборку для таблицы, если ваше предложение where включает критерии, ограничивающие раздел, в котором могут существовать результаты, поиск будет сканировать только этот раздел, а не полное сканирование таблицы. Вы можете увидеть это в действии с:

-- scans entire table
explain partitions select * from Books where title='%title%';

против чего-то вроде:

-- scans just one partition
explain partitions select * from Books 
where year(pubDate)=2010
and title='%title%'; 

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

Даже если вы решите разбить дату, может помочь раздел таблицы, скажем, за год (int) (при условии, что поиск всегда будет указывать год).

0 голосов
/ 24 мая 2010

Используйте обычное поле даты и времени.Вы всегда можете переключиться на отдельные компоненты, если производительность становится проблемой.Старайтесь избегать преждевременной оптимизации - во многих случаях YAGNI.Вы можете использовать и поле даты и времени и методологию отдельных компонентов, поскольку у них обоих есть свои сильные стороны.

...