Никакой вменяемой документации не нашел вообще нигде.
я пока не прочитал юнит тест вообще не понял как это работает, видимо у разработчиков мозг начинает мыслить на том же языке на котором он пишет, вот и перестаем мы понимать внятную английскую речь…
От комментария у меня двойственное впечатление… толи плакать толи смеяться.
Первый — все по делу. Все мои исправления действительны относительно сорцов MySQL 5.5.15. Можно поподробнее рассказать, что именно я нашел и почему это должно входить в какой-то пакет поставки?
А вот ссылка но официальную документацию просто умиляет :) судя по статье я похож на человека который не удосужился залезть в первую выдаваемую ссылку с гугла на GRANT PROXY? Если поискать в документе слово «тынц» можно будет найти практически ту же самую ссылку. Официальная документация безбожно уныла. Мало информации это значит никто пока её не заюзал. Нету плагинов для ldap. Нету комментариев где и что падает и не работает, нету людей которые этим реально пользовались. Вот что хочеться увидеть.
Чтобы сделать из этого конфетку надо в начале поработать с этим с пол годика и понять, где все камни. Ввиду того, что решение новое и до 5.5.7 его не было, не успел. Потестирую с репликой, посмотрю ещё пару интересных мне моментов, тогда можно будет оборачивать. А пока, пишу что есть, в надежде, что надутся добрые люди которые заюзают эту фичу и можно будет пообщаться.
Спасибо за поддержку, честно говоря нулевая реакция на статью меня несколько удивила…
Несколько лет я занимался Oracle, и поверьте если делать на нем серьезные вещи, то в нем находиться столько багов, что сложно представить. На его оптимизатор начинаешь плеваться, постоянные ORA-600 (а их там знаете сколько) выискиваешь на metalink пихая туда корки от unix процессов. Как только начнинаешь юзать новые фичи — понимаешь что они нифига не работают так, как описано в документации, а если и работают, то крайне неоптимально!
Tweeter — работал на MySQL (раньше)
Facebook — работает на MySQL
Google — очень активно испольщует MySQL
К чему я все это? А к тому что у каждой БД есть свои недостатки, но если вы профессионал, то вы научитесь их обходить. Кончено проще сказать — переходи на другой софт, но поверьте мне это не панацея. Может статья и не простая и не всем удасться применить её на практике, но когда я попробывал проанализировать эту схему на одном из своих промышленных серверов я офигел:
— не правильно выбран движок для некоторых очень важных таблиц
— с кэшами драйвера JDBC какая-то жопа
— чекпойнты излишне агрессивны
— размер лог файлов задан неверно
и т.д.
Анализ данной схемы позволяет вам оценить на сколько верно вы выбрали архитектуру всего решения в целом, да потребуются дополнительные навыки, но а кому сейчас легко?
Платить деньги за СУБД и за дорогое железо это не наши методы.
Наши это: оптимизация архитектуры, глубокое понимание проблемной области.
Тот же Oracle легко роняется обычними запросами, если их пишут криворукие программисты, или же администраторы настраивают так параметры, что жить на БД становится невозможно. На текущий момент performance_schema не готова к выходу в массы, но те кто желает понять как именно реагирует инстанс на изменение параметров — с радостью воспользуются тем инструментарием которые эта схема предоставляет.
суровое замечание, только не понял какой инструмент используется не для своей задачи? MySQL используется в очень крупных конторах, работающих с очень большим трафиком. Только вот разработка MySQL отстает сильно и часть кода приходится дописывать ручками. К примеру тот же анализ таблиц и индексов, который обещают в 5.6 уже давно написан в Google.
на данный момент MySQL является одной из лучшех open source БД, которая способна выполнять большое количество транзакций в секунду. И тем кто не может позволить себе купить Oracle с его мощными инструментами анализа и сверх навороченным оптимизатором приходиться использовать то что есть.
но в общем конечно замечание верное, ибо performance_schema в том виде в котором она есть, на данный момент в основе — инструмент разработчика. Хотя я вроде не сишник, а спокойно понимаю что написано в исходниках, думаю другим информация подобного рода тоже будет не лишней. Посмотреть самый верхний мьютекс и залезть в инет узнать что и как вроде несложная задача.
судя по оценкам и обилию комментариев, я так понимаю, большинство людей читающих этот блог с вами согласны… думал скинуть ещё пару статей подобного рода, но вижу, что таски такого рода не сильно интересны. В следующий раз постараюсь выбрать тему для поста «ближе к народу»
хм… я вообще то всегда думал, что эта проблема решается созданием составного индекса.
то, что MySQL не умеет грамотно опеределять какой именно индекс использовать в запросе, это и ежу понятно, и именно по этому необходимо разруливать такие случаи самостоятельно, а решение с явным указанием индекса всегда будет наихудшим, ибо может перестать работать. когда гистограмма распределения станет другой, или появятся дополнительный колонки в таблице. Оно просто иллюстрирует, что если у вас значения индекса, который используется в условии WHERE, не является высокоселективным, то алгоритмы использемые MySQL для оптимизации в этом случае явно далеки от идеала, и с этим надо бороться. Просто надо бороться, а как это уже другой вопрос, который в каждой конкретной ситуации надо решать своим способом.
1. это не запрос а декларация курсоров, если поставить декларацию перехвата исключения в другом месте — вы не соберетесь. Перехват исключения отрабатывает если запрос не вернул данных, а не только при окончании курсора, и с ним есть пара подводных камней.
2. это просто best practice чтоб при вызове процедуры какждый раз на стороне драйвера JDBC не возникало надоедливое предупреждение table already exists, вроде в MySQL 5.5 поменяли механизм проброски исключений, чтобы иметь возможность обрабатывать множественные исключения в каскаде процедур, и вполне возможно этот код работает уже не так четко, как раньше.
По русским источникм я к сожалению не специалист.
Изначально рисунков не планироволось вообще, но так как без них получилось бы очень много текста, который надо внимательно читать, чтобы понять суть, то я решил перенести его в иллюстрации. Так визуально легче. Естественно рисовать их пришлось с ноля. Жаль хабр эффект не воспринимает svg, так бы я прям исходниками его выложил, в векторе.
да, согласен, а ещё когда count считаешь он pk подхватывает и сканит всю таблицу, ибо innodb, вместо какого-нибудь другого индекса меньшего по размеру.
если бы я описал все что хотел, боюсь это точно никто не стал бы читать.
к сожалению пришлось отрезать много интересного материала
Да точно не тот план вставил, дело в том что примеры готовил пару дней, складывая всю нужную информацию в файл запросов, а статью написал за пару тройку часов ночью, я бы даже сказал ранним утром, и запостил в ней не тот план исполнения.
Подправил план. Теперь там fullscan :)
А написанный ранее план будет работать в том случае если все колонки запроса содержаться в индексе (это был один из неудачных экпериментов по оптимизации я его тут описывать не стал и так слишком объемная статья вышла, тем более index_ffs MySQL тоже делает крайне медленно)
Можно, но если только в другой статье, так как вопрос большой, я просто сикнул наводки на темы которые можно почитать в гугле, если не понятно с чего начинать изучение оптимизации запросов. Если в кратце; в MySQL к сожалению нет такого инструмента как trace и любую информацию необходимую для понимая того как же именно выполняется запрос можно получить 3-мя способами
— explain (extended!)
— set profiling
— performance_schema
Первый показывает план выполнения а так же то как именно был переписан запрос. Второй поясняет на что в основе было затрачено время: фетч, передача данных и т.д. Это первые две секции из trace файла Oracle. Но вот дальше все обстоит гораздо хуже. Трейс восьмого (вроде бы) уровня для Oracle дает подробную информацию по событиям ожидания, которая показывет физические и логические чтения, ожидание блокирововк и так далее. performance_schema, которая появилась в MySQL 5.5 позволяет посмотреть ряд событий, но далеко не все, а именно основной упор сделан на дисковые чтения и мьютексы. К сожалению в целом по базе, с разбивкой по событиям. Т.е. если БД тормозит, то есть шанс, что причина может быть найдена после изучения performance_schema, но не факт.
действительно есть пара интересных статей, и что немаловажно с картинками, что сильно улучшает восприятие.
жаль половина статей там только про MySQL 6.0 в котором полностью переписали оптимизатор (который вроде как уже свернули), PostgreSQL и MariDB.
Еще подобных ресурсов не знаете? По MySQL напрочь отсутствуют данные подобного рода в internet. И все изыскания приходится делать методом проб и ошибок, что конечно частенько сказывается на качестве получаемого результата.
Да именно это и и мелось ввиду, что идет полное сканирование таблицы по индексу, что и показывает план. Но дело в том, что запрос выбирает max(record_value), которое отсутствует в индексе, так что это не чистый index_ffs это сканирование по индексу с соответствующим заходом в таблицу, что ИМХО ещё хуже чем fullscan. Хотя конечно что лучше, а что хуже для MySQL не всегда понятно.
Писал в 3 утра — не все мысли сформулированы точно. Спасибо за указание на ошибку — подправлю в статье. И заодно проверю, что за план там вставлен, как-то на свежую голову он мне не внушает доверия :)
Целью данной фразы было не указать на то что cost based оптимизатор в MySQL отсутствует, а то что он из рук вон плохо оптимизирует запросы. Думаю то, что в оптимизатор Oracle, прекрасно работающий с гистограммами и динамически анализирующий результат запроса полученный после применения предикатов доступа и даже фильтрации, не идет ни в какое сравнение с оптимизатором MySQL и так понятно.
Примеры неудачной оптимизации MySQL я как раз и постарался сдесь привести и описать что не так.
Могу посоветовать почитать темы связанные с багом #5982 там много всего интересного, однако это выяняеся просто если посмотреть в performance_schema в момент выполнеяния запроса там будет идти многоблочное чтение именно этого файла данных (если конечно у вас выставлен параметр innobd_file_per_table если не ошибаюсь)
Oracle 10 оптимизировал данный запрос успешно, используя индекс целиком, при наличии гистограмм по указанным колонкам, при чем там можно явно указать хинт /*+ cardinality(1)*/ (вроде так пишется) и оптимизатор все сделает нормально. Я понимаю ваш вопрос могу на него ответить вот такими запросами:
select b.attr_attr_id,
max(b.record_date),
min(b.record_date),
max(b.record_value),
count(1)
from (select *
from attributes where attr_id > 499) a
straight_join
big_table b force index (idx_big_table_attr_date)
on b.attr_attr_id = a.attr_id and b.record_date between a.start_date and a.end_date
group by b.attr_attr_id;
select b.attr_attr_id,
max(b.record_date),
min(b.record_date),
max(b.record_value),
count(1)
from (select *
from attributes where attr_id > 450) a
straight_join
big_table b force index (idx_big_table_attr_date)
on b.attr_attr_id = a.attr_id and b.record_date between a.start_date and a.end_date
group by b.attr_attr_id;
Первый отрабатывает мгновенно — второй бесконечно время, хотя время выполнения должно вызрасти всего в 50 раз…
Не зря эту ошибку завели как багу оптимизатора :) хотя конечно сам MySQL так не считает.
вот тут сложно не согласиться!
думаю demark имел ввиду особенность движка InnoDB, которая позволяет ему работать быстро только в том случае — когда все данные помещаются в оперативную память (я вот к примеру слышал что PostgeSQL работает по иным алгоритмам и ему не надо так много ОЗУ)
Во всех статьях по оптимизации СУБД MySQL как раз делаеться упор на то, что надо выделить БОЛЬШЕ ресурсов, ибо при низких значениях inno_db пулов этот engine начитнает работать из рук вон плохо.
я пока не прочитал юнит тест вообще не понял как это работает, видимо у разработчиков мозг начинает мыслить на том же языке на котором он пишет, вот и перестаем мы понимать внятную английскую речь…
Первый — все по делу. Все мои исправления действительны относительно сорцов MySQL 5.5.15. Можно поподробнее рассказать, что именно я нашел и почему это должно входить в какой-то пакет поставки?
А вот ссылка но официальную документацию просто умиляет :) судя по статье я похож на человека который не удосужился залезть в первую выдаваемую ссылку с гугла на GRANT PROXY? Если поискать в документе слово «тынц» можно будет найти практически ту же самую ссылку. Официальная документация безбожно уныла. Мало информации это значит никто пока её не заюзал. Нету плагинов для ldap. Нету комментариев где и что падает и не работает, нету людей которые этим реально пользовались. Вот что хочеться увидеть.
Несколько лет я занимался Oracle, и поверьте если делать на нем серьезные вещи, то в нем находиться столько багов, что сложно представить. На его оптимизатор начинаешь плеваться, постоянные ORA-600 (а их там знаете сколько) выискиваешь на metalink пихая туда корки от unix процессов. Как только начнинаешь юзать новые фичи — понимаешь что они нифига не работают так, как описано в документации, а если и работают, то крайне неоптимально!
Tweeter — работал на MySQL (раньше)
Facebook — работает на MySQL
Google — очень активно испольщует MySQL
К чему я все это? А к тому что у каждой БД есть свои недостатки, но если вы профессионал, то вы научитесь их обходить. Кончено проще сказать — переходи на другой софт, но поверьте мне это не панацея. Может статья и не простая и не всем удасться применить её на практике, но когда я попробывал проанализировать эту схему на одном из своих промышленных серверов я офигел:
— не правильно выбран движок для некоторых очень важных таблиц
— с кэшами драйвера JDBC какая-то жопа
— чекпойнты излишне агрессивны
— размер лог файлов задан неверно
и т.д.
Анализ данной схемы позволяет вам оценить на сколько верно вы выбрали архитектуру всего решения в целом, да потребуются дополнительные навыки, но а кому сейчас легко?
Наши это: оптимизация архитектуры, глубокое понимание проблемной области.
Тот же Oracle легко роняется обычними запросами, если их пишут криворукие программисты, или же администраторы настраивают так параметры, что жить на БД становится невозможно. На текущий момент performance_schema не готова к выходу в массы, но те кто желает понять как именно реагирует инстанс на изменение параметров — с радостью воспользуются тем инструментарием которые эта схема предоставляет.
на данный момент MySQL является одной из лучшех open source БД, которая способна выполнять большое количество транзакций в секунду. И тем кто не может позволить себе купить Oracle с его мощными инструментами анализа и сверх навороченным оптимизатором приходиться использовать то что есть.
но в общем конечно замечание верное, ибо performance_schema в том виде в котором она есть, на данный момент в основе — инструмент разработчика. Хотя я вроде не сишник, а спокойно понимаю что написано в исходниках, думаю другим информация подобного рода тоже будет не лишней. Посмотреть самый верхний мьютекс и залезть в инет узнать что и как вроде несложная задача.
судя по оценкам и обилию комментариев, я так понимаю, большинство людей читающих этот блог с вами согласны… думал скинуть ещё пару статей подобного рода, но вижу, что таски такого рода не сильно интересны. В следующий раз постараюсь выбрать тему для поста «ближе к народу»
то, что MySQL не умеет грамотно опеределять какой именно индекс использовать в запросе, это и ежу понятно, и именно по этому необходимо разруливать такие случаи самостоятельно, а решение с явным указанием индекса всегда будет наихудшим, ибо может перестать работать. когда гистограмма распределения станет другой, или появятся дополнительный колонки в таблице. Оно просто иллюстрирует, что если у вас значения индекса, который используется в условии WHERE, не является высокоселективным, то алгоритмы использемые MySQL для оптимизации в этом случае явно далеки от идеала, и с этим надо бороться. Просто надо бороться, а как это уже другой вопрос, который в каждой конкретной ситуации надо решать своим способом.
2. это просто best practice чтоб при вызове процедуры какждый раз на стороне драйвера JDBC не возникало надоедливое предупреждение table already exists, вроде в MySQL 5.5 поменяли механизм проброски исключений, чтобы иметь возможность обрабатывать множественные исключения в каскаде процедур, и вполне возможно этот код работает уже не так четко, как раньше.
По русским источникм я к сожалению не специалист.
если бы я описал все что хотел, боюсь это точно никто не стал бы читать.
к сожалению пришлось отрезать много интересного материала
Подправил план. Теперь там fullscan :)
А написанный ранее план будет работать в том случае если все колонки запроса содержаться в индексе (это был один из неудачных экпериментов по оптимизации я его тут описывать не стал и так слишком объемная статья вышла, тем более index_ffs MySQL тоже делает крайне медленно)
— explain (extended!)
— set profiling
— performance_schema
Первый показывает план выполнения а так же то как именно был переписан запрос. Второй поясняет на что в основе было затрачено время: фетч, передача данных и т.д. Это первые две секции из trace файла Oracle. Но вот дальше все обстоит гораздо хуже. Трейс восьмого (вроде бы) уровня для Oracle дает подробную информацию по событиям ожидания, которая показывет физические и логические чтения, ожидание блокирововк и так далее. performance_schema, которая появилась в MySQL 5.5 позволяет посмотреть ряд событий, но далеко не все, а именно основной упор сделан на дисковые чтения и мьютексы. К сожалению в целом по базе, с разбивкой по событиям. Т.е. если БД тормозит, то есть шанс, что причина может быть найдена после изучения performance_schema, но не факт.
блог
жаль автор его забросил, дельные вещи писал…
жаль половина статей там только про MySQL 6.0 в котором полностью переписали оптимизатор (который вроде как уже свернули), PostgreSQL и MariDB.
Еще подобных ресурсов не знаете? По MySQL напрочь отсутствуют данные подобного рода в internet. И все изыскания приходится делать методом проб и ошибок, что конечно частенько сказывается на качестве получаемого результата.
Писал в 3 утра — не все мысли сформулированы точно. Спасибо за указание на ошибку — подправлю в статье. И заодно проверю, что за план там вставлен, как-то на свежую голову он мне не внушает доверия :)
Примеры неудачной оптимизации MySQL я как раз и постарался сдесь привести и описать что не так.
Первый отрабатывает мгновенно — второй бесконечно время, хотя время выполнения должно вызрасти всего в 50 раз…
Не зря эту ошибку завели как багу оптимизатора :) хотя конечно сам MySQL так не считает.
думаю demark имел ввиду особенность движка InnoDB, которая позволяет ему работать быстро только в том случае — когда все данные помещаются в оперативную память (я вот к примеру слышал что PostgeSQL работает по иным алгоритмам и ему не надо так много ОЗУ)
Во всех статьях по оптимизации СУБД MySQL как раз делаеться упор на то, что надо выделить БОЛЬШЕ ресурсов, ибо при низких значениях inno_db пулов этот engine начитнает работать из рук вон плохо.