The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступна для загрузки предварительная версия 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.

  1. Главная ссылка к новости (http://www.mysql.com/news-and-...)
  2. OpenNews: Набор полезных патчей и идей по развитию MySQL
  3. OpenNews: OurDelta - альтернативная сборка MySQL
  4. OpenNews: Google открыл доступ к своим утилитам для MySQL
Лицензия: CC-BY
Тип: Интересно / Программы
Короткая ссылка: https://opennet.ru/21379-mysql
Ключевые слова: mysql
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (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 [ответить]  
  • +/
    А я так надеялся что репликации допилят до более-менее потребного состояния :(.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру