Представлена (http://www.mysql.com/news-and-events/generate-article.php?id...) бета версия новой ветки MySQL 5.4 (http://dev.mysql.com/doc/mysql-5.4-features/en/), основанной на коде MySQL 5.1.x, но содержащей ряд улучшений (http://dev.mysql.com/doc/mysql-5.4-features/en/introduction....) в плане повышения производительности и масштабируемости, главным образом за счет более полного использования возможностей современных многоядерных CPU. Предварительное тестирование, проведенное независимой компанией thePlatform,  показало 40% прирост производительности при выполнении типичных СУБД-ориентированных приложений в MySQL 5.4, по сравнению с версией 5.1.x.

В настоящий момент MySQL 5.4 доступен (http://www.mysql.com/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 дистрибутив.

Некоторые и...

URL: http://www.mysql.com/news-and-events/generate-article.php?id...
Новость: http://www.opennet.me/opennews/art.shtml?num=21379

• Доступна для загрузки предварительная версия MySQL 5.4,Sarge, 07:00 , 22-Апр-09
  • Доступна для загрузки предварительная версия MySQL 5.4,Kemm, 08:25 , 22-Апр-09
    • Доступна для загрузки предварительная версия MySQL 5.4,Sarge, 10:03 , 22-Апр-09
      • Доступна для загрузки предварительная версия MySQL 5.4,Yarick, 00:13 , 25-Апр-09
• Доступна для загрузки предварительная версия MySQL 5.4,Nas_tradamus, 10:46 , 23-Апр-09

> Новый механизм оптимизации вложенных запросов и JOIN операций,
> повышающий скорость выполнения некоторых запросов на 90%;

Надеюсь это означает, что JOIN больше не будет выполняться для всего запроса несмотря на LIMIT 3000,30
А то у меня огромные лаги были из-за этого косяка пока не додумался разбить джоин на 2 отдельных запроса :(

Не означает, естественно. Документацию читать надо: limit отрабатывается ТОЛЬКО на результирующем массиве, исключительно чтобы гигабайты зря по сети не гонять. Кроме крайне редких мелких случаев (типа LIMIT 0) они не оптимизируются от слова "ваще" и на план выполнения запроса никак не влияют.

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

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

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

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

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

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

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

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

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

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

А я так надеялся что репликации допилят до более-менее потребного состояния :(.