|
Задавайте вопросы, мы ответим
Вы не зашли.
Ребят, подскажите какой тип поля лучше использовать для индексов - DATE или DATETIME? В случае с DATE мы имеем бОльшее количество записей в индексе, но меньшее количество самих значений, а в DATETIME наоборот... Возможно что-то неправильными словами называю, но суть вопроса вроде ясна, т.к. вполне логична))
Подскажите, с каким типом поля выборка будет работать быстрее? Искать нужно как за несколько дат, так и начиная с конкретной даты/времени.
ЗЫ Помимо индексированного поля есть ещё поле DATETIME без индекса. Оба поля пока нужны, но при следующей реструктуризации одно поле уберём 
Отредактированно Neval (08.01.2011 18:33:51)
Неактивен
Вы еще забыли написать, *какая* выборка будет работать быстрее
Например, вот для этих двух выборок я бы выбрал разные варианты ответа на
Ваш вопрос:
SELECT ... FROM tablename WHERE `date` BETWEEN '2011-01-01' AND '2011-01-02';
SELECT ... FROM tablename WHERE `date` IN ('2011-01-01', '2011-01-02') AND otherfield > 7;
Неактивен
Эммм... вообще-то нужны обе))
Неактивен
т.е. получается, с WHERE `date` BETWEEN '2011-01-01' AND '2011-01-02' будет быстрее выбирать при типе DATETIME...
Но если нужны обе выборки, есть ли какой-то компромисс по ускорению обоих одним индексом? Или как лучше сделать в данном случае?
ЗЫ В таблице сейчас 35кк записей, на каждую дату приходится по 100-700к записей, которые добавляются ежедневно, запросы такие обрабатываются не быстро
Отредактированно Neval (09.01.2011 14:02:56)
Неактивен
Всё потому, что Вы пытаетесь идти от оптимизации. А надо идти от смысла. Что Вам
нужно хранить? Нужно ли Вам время? Если да — бывают ли запросы, которые ищут
«от 11 ночи вчера до 9 утра послезавтра», или они все по датам? Может, Вам вообще
не нужно время никогда?
Неактивен
Скажем так, в основном нужен поиск по датам "от и до" (как правило, указывается промежуток, а не конкретные выборочные даты), но бывают моменты, когда ищутся записи с конкретного времени, в таких случаях время указывается для уточнения и уменьшения количества результирующего множества.
А хранить время нам нужно
Отредактированно Neval (11.01.2011 00:49:34)
Неактивен
Тогда я бы хранил отдельно DATE, отдельно TIME, чтобы по DATE можно было делать IN(),
и потом можно было использовать хвостик ключа. А TIME-запросы будут промахиваться
сильно по индексу, но тут уж ничего не поделаешь.
Неактивен
Впрочем, туплю. Все равно IN даст RANGE. Так что TIMESTAMP
Неактивен
Были мысли касательно разделения даты и времени, но грабли в том, что понятия здесь разные, поле added хранит дату добавления записи, а поле sended - дату и время фактической обработки записи, так-что получается, даты могут отличаться
Т.е. хотите сказать, что при IN (при подряд идущих значениях) оптимизатор будет действовать так же, как и при BETWEEN?
Неактивен
Уху.
Неактивен
хмм, а я вот прогаммеров "гоняю", если они TIMESTAMP используют вместо int unsig. 8 байт против 4 у int unsig. имхо лучше мускуль не грузить тем, что можно вынести в приложение.
хотя если время выполнения запросов в данном случае будет более 500мс, то можно и не экономить.
Неактивен
Открою Вам страшную тайну — TIMESTAMP 4 байта в MySQL, даже в 64-битных ОС.
Да, проблема 2038 актуальна 
Неактивен
ой, выше видел datetime и все перепуталось. не пинайте сильно.
Неактивен
