MySQL *

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.

Казалось бы, сделку Oracle и Sun уже одобрили все инстанции. Однако, один из основных разработчиков СУБД MySQL Монти Видениус никак не может смириться с тем, что его детище попало в плохие руки. На днях стало известно, что Монти подал апелляцию в Европейский суд, требуя аннулировать решение европейский властей, которые одобрили сделку.

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

В интервью Financial Times сам Монти Видениус сказал, что не хочет комментировать содержание апелляции, пока не дождётся официального ответа Oracle. Он только добавил, что декларация Oracle «не стоит той бумаги, на которой напечатана» и он хотел бы получить реальные гарантии.

Монти Видениус также сказал, что оплатил подачу апелляции из собственного кармана, но действует в интересах множества людей, подписавших онлайновую петицию в защиту MySQL.

Есть идея провести очередную встречу Moscow MySQL User Group 17 мая(пн) в районе м.ВДНХ в 19:30 — неформальное общение и разговоры… MySQL и что ждет всех нас в
будующем :-)

Участие традиционно бесплатное.
Регистрация в топике
groups.google.ru/group/moscow-mysql-user-group/browse_thread/thread/4ce04ca2425d353

Указывайте полное ФИО, компанию, когда сможете придти… встреча до 22:00

Запись на встречу до 15мая 12:00

Ведущий встречи — Костя Осипов (Team Lead, Server Runtime, MySQL)

Гости встречи… надеюсь их не совсем замучают на DEVCONF 2010 ;-)

Michael Widenius Co-Founder of MySQL AB
Author of the MySQL Server and MariaDB fork
monty-says.blogspot.com

Сергей Петруня (http://s.petrunia.net/blog) работает в Monty Program
Ab и является одним из разработчиков MariaDB. Его предыдущее место
работы — MySQL Ab, где он работал над оптимизатором запросов и закодировал
такие оптимизации как index_merge, partition pruning другие.

Алик Рубин, MySQL, Норвегия
Готов обсуждать (MySQL replication,MySQL cluster, DRBD/HeartBeat/ MySQL, Shared Disk)

До встречи на MMUG!

Собственно, сегодня был запощен топик "Сравниваем производительность MongoDB и MySQL на простом примере", в котором указывалось, что MongoDB превышает по производительности MySQL в разы. Хех, когда такое пишут — я сразу лезу проверять и сомневаться. Я полез в исходники оригинального теста (спасибо за публикацию). И как оказалось автор оригинального топика сделал ошибку в три символа и на самом деле не все так:

1. В оригинале: MongoDB быстрее MySQL пишет в 1.5 раза (ДА, правда у меня в 3 раза)
2. В оригинале: MongoDB быстрее MySQL читает в 10 раз (НЕТ, на самом деле — MongoDB примерно на равных плюс-минус 10-30%)
3. InnoDB vs MyISAM — плюс-минус (в оригинале не тестировалось)

Сравнение здесь происходит только как key-value storage (запись-чтение по primary key).


На графике — число операций в секунду, (больше — лучше), шкала логарифмическая.
Последняя строка — то, что тестировал автор оригинального топика (неправильное, не в критику — все мы ошибаемся и учимся).

А теперь подробнее об ошибке…

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Недавно пришлось выполнить махинацию с БД которая, как кажется на первый взгляд, совершенно невыполнима средствами MySQL. Перед глазами у меня была таблица товаров, сортировка которых осуществляется вспомогательным столбцом `order_num` ('порядковый номер'): она позволяет задавать ручную сортировку товаров.
Но вот потребовалось автоматически заполнить этот столбец так, чтобы товары оказались отсортированы по названию: то есть, с рядом ограничений, изменить столбец `order_num` во всей таблице. Очень хотелось обойтись средствами MySQL без привлечения каких-либо дополнительных инструментов, и задача была решена :)

Сложность задачи также в том, что MySQL не умеет делать UPDATE таблицы и одновременно читать из неё: в MyISAM таблица эксклюзивно блокируется при записи и нет возможности произвести чтение в подзапросе.

Сегодня мне пришло довольно большое письмо от сторонников кампании helpmysql.org. На мой взгляд, довольно любопытное. Решил им поделиться, ну и попросить поучаствовать в этой кампании.

PS. В письме много ссылок, некоторые (на мой взгляд важные) я оставлю кликабильными, остальные нет — что бы в спаме не заподозрили =)

К сожалению, несмотря на то, что ваши вопросы Монти были отправлены задолго до конца декабря, ответить на них он сумел несколько позже запланированного срока, что, впрочем, не умаляет интересности и актуальности его ответов (англоязычный оригинал ответов Майкла на ваши вопросы можно скачать здесь (RTF-файл, 16,6 Кбайт); ниже дан наш перевод, он может быть не идеален, так что буду рад, если укажете на возможные ошибки).

Напомню, что Майкл «Монти» Видеинус — это один из основных разработчиков популярной СУБД MySQL, которую, в свою очередь, хочет заиметь Oracle Corporation. Такое положение дел Монти по понятным причинам совершенно не устраивает, в связи с чем он в прошлом году опубликовал у себя в блоге соответствующую заметку, обращаясь за помощью к комьюнити.

Итак, Монти, вы получили вопросы от Habrahabr.ru? Люди волнуются, что вы так долго не отвечаете.
Я только что заметил. Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org, это заняло почти всё моё время в последние дни.

Как вы пришли к идее создания MySQL в 1994 году? Почему вообще решили этим заняться? Что не устраивало в существующих решениях?
MySQL была основана на более старой программе для баз данных Unireg, которую я начал разрабатывать в 1982-м. Это был генератор приложений на основе tty (screen). С помощью Unireg мы создавали прикладные программы для наших клиентов.

В 1993-м нам понадобилось обеспечить клиентам доступ к их базам Unireg через интернет. Чтобы решить эту проблему, я сделал поверх Unireg слой SQL (поскольку я полагал, что SQL будет легко встроить в скрипты HTML), а также драйвер ODBC.

Другими словами, первоначальной задачей MySQL было решение наших собственных проблем, чтобы предоставить клиентам доступ к данным.

В качестве альтернативного варианта мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и её нельзя было легко встраивать в HTML-страницы.

Представляю вниманию общественности перевод достаточно большой статьи об использовании MySQL на ZFS, а так же сравнительное тестирование ZFS и UFS.

Компания Oracle опубликовала пресс-релиз в котором дала официальные обещания, касающиеся политики дальнейшего развития проекта MySQL. В представленном списке обязательств учтены все пожелания, озвученные представителями Еврокомиссии и представителями независимого сообщества разработчиков MySQL.

Я думаю многие знают о Sypex Dumper, если не знают то это менеджер для работы с MySQL, написанный на php и запускаемый естественно на сервере, раньше он поддерживал только функции импорта \ экспорта БД, Но после 2 летнего перерыва автор выпустил новую версию!
Встречайте Sypex Dumper 2.0.1

Так получилось, что я довольно давно не работал с MySQL, поскольку в Рамблере используется, в основном, PostgreSQL. Сейчас у меня, наконец, появилось свободное время, и я решил догнать упущенное. Как выяснилось, за последние полтора года в мире MySQL изменилось довольно многое.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

В недавнем своем топике я приводил три на мой взгляд интересные задачи по MySQL с желанием посмотреть на возможные решения хабралюдьми. Как я и обещал, я привожу свои решения этих задач. Для того, чтоб текст был интересным и познавательным я решил детально разжевать что зачем и как. Итак…

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

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

Итак, как пользоваться:

Буквально несколько часов назад, после внимательного изучения комментариев вот к этому топику я был несколько удивлен что многие не очень любят использовать условия HAVING и похоже другие возможности СУБД. Скажу прямо — мне очень понравилась обсуждение простейшего и не работающего запроса, в результате которого многие узнали для себя много нового и познавательного (это мое личное мнение). Поэтому я решил сделать вот что — вывести три моих самых любимых задачи по знанию SQL (MySQL) на суд общественности.

Данные задачи абсолютно реальные, и в отдаленном светлом прошлом действительно имели место, и были благополучно решены жертвой некоторого количества рабочего времени и нервных клеток. Я уверен на 100% что они актуальны и по сей день, и будут актуальны еще долго. Сложными их назвать нельзя, но и очень простыми тоже (в зависимости от уровня подготовки конечно).

Здравствуйте. В этой статье я хотел бы написать про один очень интересный способ хранения иерархических структур в базах данных, не относящийся при этом к общепринятым и общеизвестным трём (Adjacency List, Nested Set, Materialized Path). Я не встречал в интернете упоминания о нём, о чём очень удивлен, ведь, по моему мнению, — это лучший и единственный способ хранить иерархические структуры. При разработке console-like форума я воспользовался именно этим способом, о чём ни на грамм не жалею. Это авторская статья и ни одно предложение не было вставлено метотодом копипаста.

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Цель этой статьи — дать краткий, очень сжатый обзор движков, для того, чтобы статьей можно было пользоваться при выборе движка на этапе проектирования \ создания \ оптимизации таблицы. Предполагается, что читатель знает суть вопроса по крайней мере поверхностно и способен сам отыскать всю дополнительную информацию (вопросы в комментах можно задавать всегда :) )

Один хороший человек хочет попасть на хабр. Для подтверждения своих благих намерений он написал статью, которую я привожу вам.

Наверняка многие знают о существовании в mySQL функции FOUND_ROWS(). Её чаще всего используют для подсчета общего числа строк в таблице, удовлетворяющих заданным условиям. Используют её обычно совместно с директивой SQL_CALC_FOUND_ROWS следующим образом:

Mysql> SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE column > 1 LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом второго запроса будет общее количество строк в таблице «table», удовлетворяющих условию «column > 1» (а не только тех, что были возвращены первым запросом).
Следует учитывать некоторые особенности этой функции, когда используете её без директивы SQL_CALC_FOUND_ROWS, о чём добросовестно предупреждает документация mySQL: в этом случае она вернёт общее количество обработанных строк (не возвращённых!). Например:

Mysql> SELECT * FROM table LIMIT 0, 50;
Mysql> SELECT FOUND_ROWS();

Результатом, как и ожидается, будет «50». Но следующие запросы вернут не слишком ожидаемый результат:

Mysql> SELECT * FROM table WHERE column > 1 LIMIT 50, 50;
Mysql> SELECT FOUND_ROWS();

Несмотря на то, что первый запрос вернёт 50 строк, результатом будет «100», т.к. mySQL пришлось просмотреть именно 100 строк.