Archil
Новичок
Ничего не изменял, в понедельник ещё раз все проверю.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
@Archil, Полностью согласен что за такие первичные индексы надо отрывать все что только можно, а потом догонять доотрывать все что нельзя.
Неудивлен что myisam быстрее, но это не заслуга myisam как движка, а косяк структуры таблицы.
Прежде чем создавать какой либо индекс, надо понимать как хранятся эти индексы, какие типы идексов могут быть и вообще что такое индекс. Т.е. например для btree индекса составной индекс по a, b это совсем не одно и тоже что и составной индекс по b, a и т.д. Потом переходить к конкретным реализациям индексов в конкретных движках Myisam/Innodb, а потом если все выше сказаное будет осмыслено, то почитать насчет кластерных индексов и партиал индексах Innodb. Но минимальное знание которое необходимо - это понимание что индекс это не магия, которая магическим образом ускоряет выборку данных и напихав индексов все выборки будут быстрые белые и пушистые.
P.S. Составные примари ключи очень полезная вещь, но только при правильном применении и только для очень специфических наборов данных при очень небольшом количестве типов запросов. В 99,99% случаев правильнее использовать простой примари + набор специализированных индексов.
Неудивлен что myisam быстрее, но это не заслуга myisam как движка, а косяк структуры таблицы.
Прежде чем создавать какой либо индекс, надо понимать как хранятся эти индексы, какие типы идексов могут быть и вообще что такое индекс. Т.е. например для btree индекса составной индекс по a, b это совсем не одно и тоже что и составной индекс по b, a и т.д. Потом переходить к конкретным реализациям индексов в конкретных движках Myisam/Innodb, а потом если все выше сказаное будет осмыслено, то почитать насчет кластерных индексов и партиал индексах Innodb. Но минимальное знание которое необходимо - это понимание что индекс это не магия, которая магическим образом ускоряет выборку данных и напихав индексов все выборки будут быстрые белые и пушистые.
P.S. Составные примари ключи очень полезная вещь, но только при правильном применении и только для очень специфических наборов данных при очень небольшом количестве типов запросов. В 99,99% случаев правильнее использовать простой примари + набор специализированных индексов.
Небось табличка не такая большая, а настройки для муисама позволяют все забрать в память. Чудес не бывает.
И, да, тестировал выборки как? Надо тестировать с SQL_NO_CACHE, чтобы получать достоверные бенчи.
Ну, полторы секунды из кэша это овердофига.
Я бы предположил то у него иннодибишный индекс по какой-то причине в память не влезал, а майисамовский влез.
Либо при смене движка предложенный мной индекс подцепился таки. Вот тут полторы секунды из индекса в полтора десятка байт шириной, целиком лежащего в памяти - должно быть как раз, я думаю.
Всё просто, раньше у него в страницах была куча мусора, а при смене движка таблица перепаковалась только актуальными данными, в итоге меньше по диску елозить.
Скоро всё вернётся, если там записи часто удаляются.
Archil
Новичок
Пришлось срочным образом очищать базу, успел сделать дамп 5+ миллионов записей, приложил в сообщении.
После ваших сообщений изменил в таблице следующее:
1. Убрал старый первичный ключ, сделал поле id primary.
2. Добавил
Правильно ли я сделал?
После ваших сообщений изменил в таблице следующее:
1. Убрал старый первичный ключ, сделал поле id primary.
2. Добавил
Код:
constraint unique_key
unique (visit_guid, visit_date, sait_id, block_id, advertisement_id, teaser_group_id, teaser_id, text_block_id, custom_widget_id, banner_id, link_id, device_type, country)
)Archil
Новичок
Да, бывает такое, что они дублируются.
Вурдалак
Продвинутый новичок
Тогда у тебя какая-то кривая генерация GUID'а, потому что весь смысл GUID в том, что вероятность коллизии слишком мала.
В противном случае, зачем тебе вообще visit_guid, на который нельзя положиться в плане уникальности? Так везде и будешь таскать с собой 12 значений?
Archil
Новичок
Сам guid уникальный, но вот эта комбинация "visit_guid, visit_date, sait_id, block_id, advertisement_id, teaser_group_id, teaser_id, text_block_id, custom_widget_id, banner_id, link_id, device_type, country" может дублироваться, когда приходит с сайта.
Вурдалак
Продвинутый новичок
guid уникальный. А связка «guid + что-то» — нет?
учитывая, что там реклама, это небось уникальная кука у юзера
Вурдалак
Продвинутый новичок
В таком случае, это должно называться visitor_guid.
Archil
Новичок
Нет там никакой куку, оно называется visit_guid, потому что это есть уникальный идентификатор визита или захода на страницу, как вам удобней.
Вурдалак
Продвинутый новичок
Archil
Новичок
Неправильно выразился, голова кипит. Данные, при одном заходе, иногда приходят повторно, поэтому их надо проверять на дубли. Хотя вот сейчас понял, что можно ограничиться уникальным ключем по 2-м полям visit_guid и advertisement_id.
Вурдалак
Продвинутый новичок
GUID визита уникальный только в пределах одного рекламного объявления?
Archil
Новичок
Не, visit_guid - уникальный идентификатор визита. Во время одного визита может показаться несколько рекламных объявлений и они не могут дублироваться. Ага, не связка visit_guid и advertisement_id не катит, потому что в двух рекламных объявлениях могут быть разные тизеры, но у тизеров может быть один и тот же link_id. Поэтому нужно будет сделать индекс visit_guid, advertisement_id, banner_id, custom_widget_id, text_block_id, teaser_group_id, teaser_id. В общем все-равно нужен составной уникальный ключ, так что от него избавиться не получится.
Размер поля country и advertisement_system уменьшил. id должен быть bigint, потому что программно могут понадобиться большие числа.
Агрегирование очень не хочется делать, это сильно усложняет дело.
Прошу помочь с другими моментами.