Здравствуйте, LelicDsp, Вы писали:
LD>тогда индекс вполне можно добавить. у Вас получается 120 строк на одну страницу innodb, а селективность около 1/1000. Те даже в худшем случае равномерного случайного распределения будет в 10 раз быстрее фулскана.
Вообще вопрос был не в этом. Сразу понятно было, что индекс раз в 10 минимум ускорит данную выборку. У меня чисто было опасение, что через несколько лет может накопиться куча индексов и это приведет к заметному понижению скорости изменения данных в таблице. Но решил все-таки не заморачиваться, добавить индекс, а через 5 лет если вдруг будут проблемы с производительностью — тогда их и решать — всегда можно будет дропнуть индексы и сделать один из вариантов, которые я привел в исходном посте. Так что пока добавил один один индекс + в один имеющийся индекс добавил 1 колонку + переписал пару DAL-методов, ну и теперь все ок — вся статистика в самом худшем случае собирается в пределах 1-2 секунд, а после кеширования, либо в среднем случае — до 200 мс.
wildwind wrote: > MZ>Пофигу. Надо будет — подождут. > > Интересный подход.
Ты все на свете запросы не сможешь оптимизировать, ты в курсе ?
А речь идёт именно о них.
> MZ>А другого средства оптимизации выборок, кроме индексов, в СУБД > MZ>не существует. > > Еще интереснее.
Romanzek wrote:
> Так мускул — это ж РСУБД. Не думаю, что она разительно отличается от > оракула или других РСУБД. Ничего нового там не придумано — в этом я > уверен на 100%.
MozgC wrote:
> LD>Если много, то как они кластеризованы относительно первичного ключа? > случайно или есть корреляция? > В MySql нет кластерных индексов.
Знай же, что в MySQL, а именно в InnoDb все индексы наоборот кластерные.
MozgC wrote:
> Вообще вопрос был не в этом. Сразу понятно было, что индекс раз в 10 > минимум ускорит данную выборку. У меня чисто было опасение, что через > несколько лет может накопиться куча индексов и это приведет к заметному > понижению скорости изменения данных в таблице. Но решил все-таки не > заморачиваться, добавить индекс, а через 5 лет если вдруг будут проблемы > с производительностью — тогда их и решать — всегда можно будет дропнуть > индексы и сделать один из вариантов, которые я привел в исходном посте.
В этом и заключается печальная правда об оптимизации производительности
реляционных СУБД -- вечный балланс между производительностью выборок
и модификаций. Но думаю конкретно тебе (да и на самом деле большинству
приложений) до точки, где начинает играть производительность модификаций
ещё очень далеко. Да и выборок как правило больше в несколько раз,
так что их производительность важнее в целом для приложения.
> Так что пока добавил один один индекс + в один имеющийся индекс добавил > 1 колонку + переписал пару DAL-методов, ну и теперь все ок — вся > статистика в самом худшем случае собирается в пределах 1-2 секунд, а > после кеширования, либо в среднем случае — до 200 мс.
Вот как раз для сбора статистики производительность нигде не важна.
О чём я и говорил -- можно подождать.
Здравствуйте, Romanzek, Вы писали:
R>Так мускул — это ж РСУБД. Не думаю, что она разительно отличается от оракула или других РСУБД. Ничего нового там не придумано — в этом я уверен на 100%.
К сожалению, там местами и «старого ничего не придумано».
LD>>тогда индекс вполне можно добавить. у Вас получается 120 строк на одну страницу innodb, а селективность около 1/1000. Те даже в худшем случае равномерного случайного распределения будет в 10 раз быстрее фулскана.
MC>Вообще вопрос был не в этом. Сразу понятно было, что индекс раз в 10 минимум ускорит данную выборку. У меня чисто было опасение, что через несколько лет может накопиться куча индексов и это приведет к заметному понижению скорости изменения данных в таблице. Но решил все-таки не заморачиваться, добавить индекс, а через 5 лет если вдруг будут проблемы с производительностью — тогда их и решать — всегда можно будет дропнуть индексы и сделать один из вариантов, которые я привел в исходном посте. Так что пока добавил один один индекс + в один имеющийся индекс добавил 1 колонку + переписал пару DAL-методов, ну и теперь все ок — вся статистика в самом худшем случае собирается в пределах 1-2 секунд, а после кеширования, либо в среднем случае — до 200 мс.
Ну всегда полезно проверить все варианты
Почему может падать скорость ставки со временем?
1) увеличивается глубина btree. У Вас БД небольшая относительно, считать точно считать влом, но а) вряд ли увеличение глубины дерева на 1 уровень произойдет больше одного раза, б) все равно индекс достаточно компактный
2) увеличение вероятности необходимости перебалансировки при вставке / апдейте. тут много зависит от того как расределены значения индексируемого столбца, но по-идее этот показатель не должен сильно меняться.
3) что-то я забыл еще?
Можно еще сделать по-другому, я собственно так в боевой системе и делаю сейчас, особенно в связи с тем что там есть определенные косяки в дизайне. Настраивается мастер-слэйв репликация, на мастере индексов по-минимуму, только необходимые для OLTP. Соответственно весь OLTP-style workload идет через мастер, а вся аналитика, отчеты — со слэйва, и там уже индексы сделать нужные для отчетов, и вообще можно много индексов, в т.ч. covering (fat) индексы.
Здравствуйте, LelicDsp, Вы писали:
LD>Можно еще сделать по-другому, я собственно так в боевой системе и делаю сейчас, особенно в связи с тем что там есть определенные косяки в дизайне. Настраивается мастер-слэйв репликация, на мастере индексов по-минимуму, только необходимые для OLTP. Соответственно весь OLTP-style workload идет через мастер, а вся аналитика, отчеты — со слэйва, и там уже индексы сделать нужные для отчетов, и вообще можно много индексов, в т.ч. covering (fat) индексы.
Согласен, если надо запускать на базе тяжелые отчеты — то лучше делать это на копии. У MSSQL это замечательно делается лог шиппингом, когда дочерняя база стоит в read only
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, MasterZiv, Вы писали:
MZ>Знай же, что в MySQL, а именно в InnoDb все индексы наоборот кластерные.
Это неверное заявление. Ну, право, будьте все-таки внимательнее, сдержаннее и точнее в своих утверждениях. Во-первых, не все, т.к. кластерный индекс у таблицы может быть только один. Во-вторых, если я добавлю в таблицу только один, неуникальный, индекс, или один уникальный индекс с колонкой(ами) которая может принимать NULL-значения, то такой индекс не будет кластерным.
Здравствуйте, LelicDsp, Вы писали:
LD>Можно еще сделать по-другому, я собственно так в боевой системе и делаю сейчас, особенно в связи с тем что там есть определенные косяки в дизайне. Настраивается мастер-слэйв репликация, на мастере индексов по-минимуму, только необходимые для OLTP. Соответственно весь OLTP-style workload идет через мастер, а вся аналитика, отчеты — со слэйва, и там уже индексы сделать нужные для отчетов, и вообще можно много индексов, в т.ч. covering (fat) индексы.
Можно и так было бы сделать, но:
1) У меня веб-сайт на shared hosting'е.
2) Мне кажется что так заморачиваться нужно только при реально больших нагрузках, когда уже начинаются проблемы. Например репликация требует дополнительного надсмотра и администрирования (см. пункт 3 ниже).
3) Если вы про MySql, то на моем опыте там не очень хорошо дела с репликацией. STATEMENT based и MIXED режимы не подходят в реальной системе (регулярно время от времени всплывают ошибки репликации, в следствие чего происходит либо рассинхронизация, либо остановка вообще). Насчет ROW based репликации точно не помню, по-моему и там были проблемы. Вчера как раз опять на главном сервере настроил ROW based репликацию, посмотрим как будет работать.
MC>3) Если вы про MySql, то на моем опыте там не очень хорошо дела с репликацией. STATEMENT based и MIXED режимы не подходят в реальной системе (регулярно время от времени всплывают ошибки репликации, в следствие чего происходит либо рассинхронизация, либо остановка вообще). Насчет ROW based репликации точно не помню, по-моему и там были проблемы. Вчера как раз опять на главном сервере настроил ROW based репликацию, посмотрим как будет работать.
Пока Бог миловал тьфу-тьфу-тьфу, не считая ошибок при недостаточно большом максимальном размере пакета. Но мы, кстати, используем только statement репликацию, потому что у нас на слэйве еще и триггеры висят, которые еще дополнительные таблицы для аудита и статистики ведут.
Здравствуйте, LelicDsp, Вы писали:
LD>Пока Бог миловал тьфу-тьфу-тьфу, не считая ошибок при недостаточно большом максимальном размере пакета. Но мы, кстати, используем только statement репликацию, потому что у нас на слэйве еще и триггеры висят, которые еще дополнительные таблицы для аудита и статистики ведут.
А ХП используете? Насколько я помню большая часть проблем была от них.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, MasterZiv, Вы писали:
MZ>>Мне глубоко пофигу как на плюсы, так и на минусы.
___>Мне в принципе тоже, просто некоторых задевает
Тех же минусов могут понаставить кто угодно — особенно это любят тупенькие ламерки. Плюсы там оценки людям ставлю — может им приятно. Минусы ставлю очень очень редко.
Кластерный индекс может быть один на таблицу. В innodb — это всегда первичный ключ.
