Доступна для загрузки предварительная версия MySQL 5.4

21.04.2009 21:17

Представлена бета версия новой ветки MySQL 5.4, основанной на коде MySQL 5.1.x, но содержащей ряд улучшений в плане повышения производительности и масштабируемости, главным образом за счет более полного использования возможностей современных многоядерных CPU.

В настоящий момент MySQL 5.4 доступен для тестирования в 64-разрядных сборках для Linux и Solaris 10. В будущем будут доступны бинарные версии для Mac OS X, FreeBSD, HP-UX, IBM AIX, IBM i5/OS, Windows, Red Hat Enterprise Linux, SuSE Enterprise Linux и других популярных Linux дистрибутив.

Некоторые интересные улучшения:

Новый механизм оптимизации вложенных запросов и JOIN операций, повышающий скорость выполнения некоторых запросов на 90%;
Переработана система внутренних блокировок. Интегрированы патчи Google с оптимизацией работы InnoDB на CPU с большим числом ядер. Например, на 16 и 64 ядерных серверах наблюдается почти двойной прирост производительности. Ранее код InnoDB не мог корректно использовать более 4 CPU;
Новый алгоритм формирования запроса, более оптимально использующий оперативную память для выполнения JOIN операций при использовании MySQL Cluster;
Улучшена реализация встраиваемых процедур, добавлены полноценные средства для управления ошибками через реализацию SIGNAL/RESIGNAL функций;
Добавлена поддержка задания параметров вывода при использовании заранее подготовленных выражений (prepared statement);
Расширены возможности по доступу к данным информационной схемы для разработчиков, использующих программные интерфейсы подобные ODBC и JDBC. Например, расширен доступ к параметрам и возвращаемым типам данным, которые используются в хранимых процедурах;
Улучшена поддержка платформы Solaris, расширены средства диагностики, базирующиеся на DTrace.

Предварительное тестирование, проведенное независимой компанией thePlatform, показало 40% прирост производительности при выполнении типичных СУБД-ориентированных приложений в MySQL 5.4, по сравнению с версией 5.1.x. Тестирование MySQL 5.4 и 5.1.30, проведенное силами Sun Microsystems на сервере с 16 CPU ядрами, продемонстрировало прирост производительности на 59% при проведении стресс-теста EAStress2004.

исправить +6 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/21379-mysql

Ключевые слова: mysql

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (5)

RSS

1.5, Sarge (??), 07:00, 22/04/2009 [ответить]	+/–
> Новый механизм оптимизации вложенных запросов и JOIN операций, > повышающий скорость выполнения некоторых запросов на 90%; Надеюсь это означает, что JOIN больше не будет выполняться для всего запроса несмотря на LIMIT 3000,30 А то у меня огромные лаги были из-за этого косяка пока не додумался разбить джоин на 2 отдельных запроса :(

2.6, Kemm (?), 08:25, 22/04/2009 [^] [^^] [^^^] [ответить]	+/–
Не означает, естественно. Документацию читать надо: limit отрабатывается ТОЛЬКО на результирующем массиве, исключительно чтобы гигабайты зря по сети не гонять. Кроме крайне редких мелких случаев (типа LIMIT 0) они не оптимизируются от слова "ваще" и на план выполнения запроса никак не влияют.

3.7, Sarge (??), 10:03, 22/04/2009 [^] [^^] [^^^] [ответить]

+/–

>limit отрабатывается ТОЛЬКО на результирующем массиве,
>исключительно чтобы гигабайты зря по сети не гонять.

Неверно. В запросах без JOIN при наличии индекса по полям поиска/сортировки - этот индекс используется. Т.е. винчестер не дёргает головками в поисках данных из других столбцов, которые затем будут просто отброшены по лимиту.

И я не вижу ограничений, почему бы так же не делать при наличии джоинов. Это только вопрос продвинутости оптимизатора.

4.10, Yarick (?), 00:13, 25/04/2009 [^] [^^] [^^^] [ответить]

+/–

Повеселило. Смеялся долго и самозабвенно. Логика потрясающая.

> Неверно. В запросах без JOIN ...

Что не противоречит документации (почему - предлагаю разобраться самостоятельно).

Даже если бы и противоречило (что не так), то неужели было бы лучше, чтобы винчестер дёргал "головками в поисках данных из других столбцов, которые затем будут просто отброшены по лимиту" только в угоду тому, что в документации было бы описано обобщённое поведение, которое в простейших случаях легко оптимизируется?

(Предыдущий абзац следует рассматривать как замаскированную провокацию, так как вывод делается из заведомо ложного утверждения :-)) )

> И я не вижу ограничений ...

Замечательно. Но в оригинальном комментарии речь шла о документации. Те, кто писал запросы в соответствии с ней, очевидно, никакого выигрыша в производительности не увидели бы. А новость можно было бы озаглавить как "некорректно написанные запросы стали выполняться быстрее". Сравните "бесконечный цикл теперь завершается в гораздо раньше".

1.9, Nas_tradamus (ok), 10:46, 23/04/2009 [ответить]	+/–
А я так надеялся что репликации допилят до более-менее потребного состояния :(.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: