Pull to refresh

Comments 50

большое спасибо за статью
кое-где правда форматирование побилось — обратите внимание на второй пункт
бегом обновлять, хотя и не понял пункт 2 :)
Вы не поняли:
>> Осталось совсем немного времени до выхода MySQL 5.1.

так что рано еще
простите, я это заметил только на сайте майскула((
бегом в очередь на скачивание :)
класс, радует что разработчики не стоят на месте…
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
UFO landed and left these words here
дождемся, вернее дождались, поскольку в Google (чисто к примеру) насколько я читал стоит именно MySQL, а там запросики будь здоров и нагрузка на серваки… мягко сказать неслабая
Ну они(Google), мягко говоря, не Community-Server MySQL используют :)
UFO landed and left these words here
А у вас есть информация, что комьюинити сервер майскуля отличается функциональностью движков от энтерпрайз?

У гугли просто модифицированная ими версия майскуля, и свои расширения они обещали открывать, часть из них должна в версию 6.0 войти.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words 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
Сделайте
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 landed and left these words here
Не знаю как это работает в MySQL, но именно так как вы написали это работает в Firebird и работает весьма неплохо…

А вцелом от оптимизатора MySQL впечатления не очень… может я не умею его готовить…
>может я не умею его готовить…

Вполне вероятно :-)
index merge это запрос вида
SELECT * FROM the_table WHERE id = 1 OR age = 22
имея индексы по полю ID и индекс по полю age
Спасибо. А то тут впахиваешь и некогда за новинками следить.

Особо порадовало, что логи можно вести в таблицах. Ну и наличие events ооочень полезно
а я раньше вел логи свои в таблицах, используя триггеры
про поднаготную партишенинга можно было бы по-больше написать
остальное, по большому счему, ерунда
xpath — имхо, вообще, бред. дань моде на xml databases
В целом — неплохая выжимка.
Но немного прокомментирую:

>> Разбиение по хеш-функции. В этом виде разбиения можно указать функцию, по которой будут разделяться данные:

На самом деле, указывается выражение, результат которого будет хешироваться, а по результату хеширования mysql будет определять в какую партицию попадет искомая строка. Подобная схема обычно используется для равномерного распределения данных по заданному количеству партиций.

Стоило также рассказать о «Composite partitioning» (субпартиционировании).

>> События (events)

На мой взгляд термин получился неправильный. Mysql использует формулировку «Event scheduler», что можно смело перевести как, скажем, «планировщик задач». Будет намного нагляднее.

>> 4. Удобство администрирования: Начиная с версии MySQL 5.1 появилась возможность сохранения логов сервера в таблицах.

А тут стоило упомянуть, что при сохранении логов в таблицы можно очень потерять в производительности (о чем недвусмысленно написано в доках), поэтому на боевом сервере лучше не включать. Либо использовать только для отладки.
> Стоило также рассказать о «Composite partitioning» (субпартиционировании).
Ну про партишенинг книгу можно отдельную написать :)

Насчет Event scheduler согласен с вами, но в большинстве русских источников используется именно термин «события»

> поэтому на боевом сервере лучше не включать
Включение general log'а естественно будет замедлять работу MySQL, даже при записи в файл. Но включить его на час другой скажем, чтобы посмотреть что там творится никого сильно не напряжет. Зато будет возможность посмотреть статистику в любых разрезах и не париться с парсерами логов.
Больше всего понравилось разбиение таблиц — круто!
в PGSQL это есть давно.
радует, что и мускул начал идти правильным путем.
mysqlslap — интересно на это будет поглядеть. насколько эффективными будут их собственные стресс-тесты на базу ??

разбиение на партиции — наконец-то :)

запись логов сервера в таблицы — сомнительное счастье. разве что только для отладочного сервера. для продакшена не дай Боже такое вообще включить :)
Это всё замечательно, вот только оптимизм по поводу «скорого выхода» — преждевременный.
MySQL 5.1 разрабатывается уже более 5 лет, и хотя на данный момент имеет статус релиз-кандидат, про сроки окончательного перехода в стабильную версию прогнозов никто не делает, т.к. есть не поправленные баги, и когда они будут исправлены — неизвестно. Хотелось бы конечно побыстрее
более 3-х лет, опечатался. извините
Уже сейчас 5.1 имеет меньше багов, чем релиз 5.0 в свое время :-), так что имхо скоро
UFO landed and left these words here
1. Это будет касаться только неиндексируемых данных, поля с индексом в памяти всегда
2. И в 5.0 бинарные поля (TEXT/BLOB) храняться на диске, а в памяти первые 256 байт
То что в 5.1 пихнули функционал Cron`а очень даже хорошо, можно будет в него вынести все/часть запросы что сейчас запускаются через скрипты по крону.
/me скромно мечтает когда-же разработчики реализуют возможность делать ограничения на размер БД средствами mysql
В новой версии добавлена возможность создания событий. Эта функциональность позволяет настроить выполнение периодических SQL запросов или процедур. Например, выполнять необходимый пересчет данных раз в день.


CREATE EVENT RECALC_SUMM
ON SCHEDULE EVERY 1 WEEK

Вы уж определитесь, либо раз в «WEEK», либо раз в «день»
«Теперь XML документ, сохраненный в таблицу, доступен пользователю в виде дерева. Можно получить любое значение из дерева и обновить лишь нужный узел.»

Это как-бы если у тебя лежит xml в поле типа «TEXT» например, или что-то спецефическое?
Да, в текстовое поле можно положить xml и работать с ним через MySQL
Выжимка про 5.1 хорошая :-), разъясняющие комменты:

Row-based replication — также используется для репликации между кластерами. Кроме того statement-based replication не может корректно передавать некоторые функции (например UUID()). Но я бы отметил псевдо режим репликации: MIXED. Он по умолчанию идет в statement, но если появляются запросы, которые не могут быть корректно переданы через statement, то автоматом временно переключается в row.
Да еще: row репликации генерит больше данных для передачи по каналу связи мастер-слейв.
Кроме того в 5.1. поддерживается циклическая репликация мастер-мастер (т.е. оба сервера являются и мастером, и слейвом).

уже на одном серваке стоит 50 а на друго 51 рц, а я даже и не знал что там будут такие новинки, надо попробовать что нибудь из этого…
никто не знает, как обновить мускул под XAMPP?
Only those users with full accounts are able to leave comments. Log in, please.