https://www.opennet.me/openforum/vsluhforumID3/52882.html Представлена (http://www.mysql.com/news-and-events/generate-article.php?id=1602) бета версия новой ветки 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.html) в плане повышения производительности и масштабируемости, главным образом за счет более полного использования возможностей современных многоядерных CPU. Предварительное тестирование, проведенное независимой компанией thePlatform, показало 40% прирост производительности при выполнении типичных СУБД-ориентированных приложений в MySQL 5.4, по сравнению с версией 5.1.x.<br><br><br>В настоящий момент 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 дистрибутив.<br><br><br><br>Некоторые и...<br><br>URL: http://www.mys https://www.opennet.me/openforum/vsluhforumID3/52882.html#10 Fri, 24 Apr 2009 20:13:03 GMT Повеселило. Смеялся долго и самозабвенно. Логика потрясающая.<br><br>&gt; Неверно. В запросах без JOIN ...<br><br>Что не противоречит документации (почему - предлагаю разобраться самостоятельно).<br><br>Даже если бы и противоречило (что не так), то неужели было бы лучше, чтобы винчестер дёргал "головками в поисках данных из других столбцов, которые затем будут просто отброшены по лимиту" только в угоду тому, что в документации было бы описано обобщённое поведение, которое в простейших случаях легко оптимизируется?<br><br>(Предыдущий абзац следует рассматривать как замаскированную провокацию, так как вывод делается из заведомо ложного утверждения :-)) )<br><br>&gt; И я не вижу ограничений ...<br><br>Замечательно. Но в оригинальном комментарии речь шла о документации. Те, кто писал запросы в соответствии с ней, очевидно, никакого выигрыша в производительности не увидели бы. А новость можно было бы озаглавить как "некорректно написанные запросы стали выполняться быстрее". Сравните "бесконечный цикл теперь завершается в гораздо раньше".<br> https://www.opennet.me/openforum/vsluhforumID3/52882.html#9 Thu, 23 Apr 2009 06:46:18 GMT А я так надеялся что репликации допилят до более-менее потребного состояния :(.<br> https://www.opennet.me/openforum/vsluhforumID3/52882.html#7 Wed, 22 Apr 2009 06:03:06 GMT &gt;limit отрабатывается ТОЛЬКО на результирующем массиве,<br>&gt;исключительно чтобы гигабайты зря по сети не гонять.<br><br>Неверно. В запросах без JOIN при наличии индекса по полям поиска/сортировки - этот индекс используется. Т.е. винчестер не дёргает головками в поисках данных из других столбцов, которые затем будут просто отброшены по лимиту.<br><br>И я не вижу ограничений, почему бы так же не делать при наличии джоинов. Это только вопрос продвинутости оптимизатора.<br> https://www.opennet.me/openforum/vsluhforumID3/52882.html#6 Wed, 22 Apr 2009 04:25:12 GMT Не означает, естественно. Документацию читать надо: limit отрабатывается ТОЛЬКО на результирующем массиве, исключительно чтобы гигабайты зря по сети не гонять. Кроме крайне редких мелких случаев (типа LIMIT 0) они не оптимизируются от слова "ваще" и на план выполнения запроса никак не влияют.<br> https://www.opennet.me/openforum/vsluhforumID3/52882.html#5 Wed, 22 Apr 2009 03:00:54 GMT &gt; Новый механизм оптимизации вложенных запросов и JOIN операций,<br>&gt; повышающий скорость выполнения некоторых запросов на 90%;<br><br>Надеюсь это означает, что JOIN больше не будет выполняться для всего запроса несмотря на LIMIT 3000,30<br>А то у меня огромные лаги были из-за этого косяка пока не додумался разбить джоин на 2 отдельных запроса :(<br>