Комментарии 50
must have хабракат
большое спасибо за статью
кое-где правда форматирование побилось — обратите внимание на второй пункт
кое-где правда форматирование побилось — обратите внимание на второй пункт
бегом обновлять, хотя и не понял пункт 2 :)
класс, радует что разработчики не стоят на месте…
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
дождемся, вернее дождались, поскольку в Google (чисто к примеру) насколько я читал стоит именно MySQL, а там запросики будь здоров и нагрузка на серваки… мягко сказать неслабая
Ну они(Google), мягко говоря, не Community-Server MySQL используют :)
Позволю себе Вам напомпить при каких обстоятельствах будет использоваться составной индекс.
Indexes Basic
• Index (A, B) can be used for
– A=5, A=5 and B=5, A=5 and B>6
• But Can't be used for
– B=6, B<2
• Only Equality/List allows second key part usage
– A=5 and B>6 — will use 2 keyparts
– A IN (1,2) and B=2 will use 2 key parts
– A>5 and B=2 will use 1 key part only
Using Indexes for Order By
• Having same index (A, B)
• A=5 ORDER BY B — Will use index
• A>5 ORDER BY B — Will not use index
• A IN (1,2) ORDER BY B – Does not help either
• A>5 ORDER BY A — Will
• ORDER BY A ASC B DESC – Does not
Indexes Basic
• Index (A, B) can be used for
– A=5, A=5 and B=5, A=5 and B>6
• But Can't be used for
– B=6, B<2
• Only Equality/List allows second key part usage
– A=5 and B>6 — will use 2 keyparts
– A IN (1,2) and B=2 will use 2 key parts
– A>5 and B=2 will use 1 key part only
Using Indexes for Order By
• Having same index (A, B)
• A=5 ORDER BY B — Will use index
• A>5 ORDER BY B — Will not use index
• A IN (1,2) ORDER BY B – Does not help either
• A>5 ORDER BY A — Will
• ORDER BY A ASC B DESC – Does not
Сделайте
SELECT * FROM the_table WHERE id = 1 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 2 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 10 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 20 AND age > 20
Ну и если допустим вам нужно вывести всего 10 отсортированых записей, то добавьте лимит и сортировку в каждый запрос, чтобы выгребал меньше. А потом и общий лимит
и сортировку.
Так каждый запрос будет использовать обе части индекса :-)
SELECT * FROM the_table WHERE id = 1 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 2 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 10 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 20 AND age > 20
Ну и если допустим вам нужно вывести всего 10 отсортированых записей, то добавьте лимит и сортировку в каждый запрос, чтобы выгребал меньше. А потом и общий лимит
и сортировку.
Так каждый запрос будет использовать обе части индекса :-)
merge индексы добавили еще в MySQL 5.0
Не знаю как это работает в MySQL, но именно так как вы написали это работает в Firebird и работает весьма неплохо…
А вцелом от оптимизатора MySQL впечатления не очень… может я не умею его готовить…
А вцелом от оптимизатора MySQL впечатления не очень… может я не умею его готовить…
index merge это запрос вида
SELECT * FROM the_table WHERE id = 1 OR age = 22
имея индексы по полю ID и индекс по полю age
SELECT * FROM the_table WHERE id = 1 OR age = 22
имея индексы по полю ID и индекс по полю age
Спасибо. А то тут впахиваешь и некогда за новинками следить.
Особо порадовало, что логи можно вести в таблицах. Ну и наличие events ооочень полезно
Особо порадовало, что логи можно вести в таблицах. Ну и наличие events ооочень полезно
про поднаготную партишенинга можно было бы по-больше написать
остальное, по большому счему, ерунда
xpath — имхо, вообще, бред. дань моде на xml databases
остальное, по большому счему, ерунда
xpath — имхо, вообще, бред. дань моде на xml databases
В целом — неплохая выжимка.
Но немного прокомментирую:
>> Разбиение по хеш-функции. В этом виде разбиения можно указать функцию, по которой будут разделяться данные:
На самом деле, указывается выражение, результат которого будет хешироваться, а по результату хеширования mysql будет определять в какую партицию попадет искомая строка. Подобная схема обычно используется для равномерного распределения данных по заданному количеству партиций.
Стоило также рассказать о «Composite partitioning» (субпартиционировании).
>> События (events)
На мой взгляд термин получился неправильный. Mysql использует формулировку «Event scheduler», что можно смело перевести как, скажем, «планировщик задач». Будет намного нагляднее.
>> 4. Удобство администрирования: Начиная с версии MySQL 5.1 появилась возможность сохранения логов сервера в таблицах.
А тут стоило упомянуть, что при сохранении логов в таблицы можно очень потерять в производительности (о чем недвусмысленно написано в доках), поэтому на боевом сервере лучше не включать. Либо использовать только для отладки.
Но немного прокомментирую:
>> Разбиение по хеш-функции. В этом виде разбиения можно указать функцию, по которой будут разделяться данные:
На самом деле, указывается выражение, результат которого будет хешироваться, а по результату хеширования mysql будет определять в какую партицию попадет искомая строка. Подобная схема обычно используется для равномерного распределения данных по заданному количеству партиций.
Стоило также рассказать о «Composite partitioning» (субпартиционировании).
>> События (events)
На мой взгляд термин получился неправильный. Mysql использует формулировку «Event scheduler», что можно смело перевести как, скажем, «планировщик задач». Будет намного нагляднее.
>> 4. Удобство администрирования: Начиная с версии MySQL 5.1 появилась возможность сохранения логов сервера в таблицах.
А тут стоило упомянуть, что при сохранении логов в таблицы можно очень потерять в производительности (о чем недвусмысленно написано в доках), поэтому на боевом сервере лучше не включать. Либо использовать только для отладки.
> Стоило также рассказать о «Composite partitioning» (субпартиционировании).
Ну про партишенинг книгу можно отдельную написать :)
Насчет Event scheduler согласен с вами, но в большинстве русских источников используется именно термин «события»
> поэтому на боевом сервере лучше не включать
Включение general log'а естественно будет замедлять работу MySQL, даже при записи в файл. Но включить его на час другой скажем, чтобы посмотреть что там творится никого сильно не напряжет. Зато будет возможность посмотреть статистику в любых разрезах и не париться с парсерами логов.
Ну про партишенинг книгу можно отдельную написать :)
Насчет Event scheduler согласен с вами, но в большинстве русских источников используется именно термин «события»
> поэтому на боевом сервере лучше не включать
Включение general log'а естественно будет замедлять работу MySQL, даже при записи в файл. Но включить его на час другой скажем, чтобы посмотреть что там творится никого сильно не напряжет. Зато будет возможность посмотреть статистику в любых разрезах и не париться с парсерами логов.
Больше всего понравилось разбиение таблиц — круто!
mysqlslap — интересно на это будет поглядеть. насколько эффективными будут их собственные стресс-тесты на базу ??
разбиение на партиции — наконец-то :)
запись логов сервера в таблицы — сомнительное счастье. разве что только для отладочного сервера. для продакшена не дай Боже такое вообще включить :)
разбиение на партиции — наконец-то :)
запись логов сервера в таблицы — сомнительное счастье. разве что только для отладочного сервера. для продакшена не дай Боже такое вообще включить :)
Это всё замечательно, вот только оптимизм по поводу «скорого выхода» — преждевременный.
MySQL 5.1 разрабатывается уже более 5 лет, и хотя на данный момент имеет статус релиз-кандидат, про сроки окончательного перехода в стабильную версию прогнозов никто не делает, т.к. есть не поправленные баги, и когда они будут исправлены — неизвестно. Хотелось бы конечно побыстрее
MySQL 5.1 разрабатывается уже более 5 лет, и хотя на данный момент имеет статус релиз-кандидат, про сроки окончательного перехода в стабильную версию прогнозов никто не делает, т.к. есть не поправленные баги, и когда они будут исправлены — неизвестно. Хотелось бы конечно побыстрее
То что в 5.1 пихнули функционал Cron`а очень даже хорошо, можно будет в него вынести все/часть запросы что сейчас запускаются через скрипты по крону.
/me скромно мечтает когда-же разработчики реализуют возможность делать ограничения на размер БД средствами mysql
/me скромно мечтает когда-же разработчики реализуют возможность делать ограничения на размер БД средствами mysql
В новой версии добавлена возможность создания событий. Эта функциональность позволяет настроить выполнение периодических SQL запросов или процедур. Например, выполнять необходимый пересчет данных раз в день.
…
CREATE EVENT RECALC_SUMM
ON SCHEDULE EVERY 1 WEEK
Вы уж определитесь, либо раз в «WEEK», либо раз в «день»
…
CREATE EVENT RECALC_SUMM
ON SCHEDULE EVERY 1 WEEK
Вы уж определитесь, либо раз в «WEEK», либо раз в «день»
«Теперь XML документ, сохраненный в таблицу, доступен пользователю в виде дерева. Можно получить любое значение из дерева и обновить лишь нужный узел.»
Это как-бы если у тебя лежит xml в поле типа «TEXT» например, или что-то спецефическое?
Это как-бы если у тебя лежит xml в поле типа «TEXT» например, или что-то спецефическое?
Выжимка про 5.1 хорошая :-), разъясняющие комменты:
Row-based replication — также используется для репликации между кластерами. Кроме того statement-based replication не может корректно передавать некоторые функции (например UUID()). Но я бы отметил псевдо режим репликации: MIXED. Он по умолчанию идет в statement, но если появляются запросы, которые не могут быть корректно переданы через statement, то автоматом временно переключается в row.
Да еще: row репликации генерит больше данных для передачи по каналу связи мастер-слейв.
Кроме того в 5.1. поддерживается циклическая репликация мастер-мастер (т.е. оба сервера являются и мастером, и слейвом).
Row-based replication — также используется для репликации между кластерами. Кроме того statement-based replication не может корректно передавать некоторые функции (например UUID()). Но я бы отметил псевдо режим репликации: MIXED. Он по умолчанию идет в statement, но если появляются запросы, которые не могут быть корректно переданы через statement, то автоматом временно переключается в row.
Да еще: row репликации генерит больше данных для передачи по каналу связи мастер-слейв.
Кроме того в 5.1. поддерживается циклическая репликация мастер-мастер (т.е. оба сервера являются и мастером, и слейвом).
уже на одном серваке стоит 50 а на друго 51 рц, а я даже и не знал что там будут такие новинки, надо попробовать что нибудь из этого…
в избранное
никто не знает, как обновить мускул под XAMPP?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нового в MySQL 5.1