Comments 50
must have хабракат
большое спасибо за статью
кое-где правда форматирование побилось — обратите внимание на второй пункт
кое-где правда форматирование побилось — обратите внимание на второй пункт
бегом обновлять, хотя и не понял пункт 2 :)
класс, радует что разработчики не стоят на месте…
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
UFO just landed and posted this here
дождемся, вернее дождались, поскольку в Google (чисто к примеру) насколько я читал стоит именно MySQL, а там запросики будь здоров и нагрузка на серваки… мягко сказать неслабая
Ну они(Google), мягко говоря, не Community-Server MySQL используют :)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Позволю себе Вам напомпить при каких обстоятельствах будет использоваться составной индекс.
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
UFO just landed and posted this here
Не знаю как это работает в 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 лет, и хотя на данный момент имеет статус релиз-кандидат, про сроки окончательного перехода в стабильную версию прогнозов никто не делает, т.к. есть не поправленные баги, и когда они будут исправлены — неизвестно. Хотелось бы конечно побыстрее
UFO just landed and posted this here
То что в 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?
Sign up to leave a comment.
Что нового в MySQL 5.1