MySQL *

Кай Арно, вице-президент MySQL AB по работе с сообществом пользователей — удивительный человек.

Он родом из Финляндии, а сам по происхождению швед (и похож этим на Линуса Торвальдса).
Он любит Россию, но не знает русского. Это не мешает ему вести свой блог на русском языке — blogs.arno.fi/fandorin.
Для этого он пишет текст на английском, переводит его на русский через Google Translate, и если в обратном переводе с русского на английский ещё что-то можно понять — публикует. Получается неплохо.

В 2001 году он продал MySQL AB половину своей компании, занимающуюся обучением MySQL, и с тех пор работал в корпорации вице-президентом по консалтинговым услугам, вице-президентом по разработке, и в итоге, с 2005 года — вице-президентом по связям с с пользовательским сообществом.

С тех пор как Sun купила MySQL AB в феврале этого года, Кай ездит по всему миру и помогает разработчикам, клиентам и сообществам пользователей Sun и MySQL найти общий язык и научиться сосуществовать в гармонии.

На днях Кай Арно приезжает в Москву и будет рассказывать о том, какой будет новая жизнь MySQL и каковы перспективы его развития при поддержке Sun — компании, которая известна своей благосклонной к opensource-сообществу политикой.

Встречу с Каем организует московская группа пользователей MySQL при поддержке клуба «Бизнес в стиле .RU».
Встреча начнется сегодня, в понедельник 1 декабря в 19-00 в Москве в здании Высшей школы экономики на улице Мясницкой, дом 20, в аудитории 124.

Времени чтобы зарегистрироваться на встречу осталось очень мало, но ещё можно успеть — для этого надо заполнить форму по адресу reg.styleru.net/registration/mmug.

Помимо Кая на встрече выступит Константин Осипов — лидер команды разработчиков ядра MySQL. Он поделится откровениями о том, что нового будет в MySQL 6.0 и расскажет о различных хитростях оптимизации работы версии 5.1, которая на прошлой неделе наконец-то вышла из статуса беты и обрела статус Generally Available.

Итак!
1. Регистрируемся.
2. Приходим к 19-00.
3. Показываем документ (паспорт, водительское удостоверение, студенческий билет, что угодно, где есть ваше имя и фамилия).
4. Проходим по указателям до аудитории и общаемся с докладчиками!

Собственно сегодня наткнулся на ссылку http://lists.mysql.com/announce/565 и сразу спешу поделиться с хабро-сообществом.

Здесь говорится, что сегодня вышел первый релиз MySQL Server 5.1.30 Generally Available (GA), который является первым релизом, рекомендованным для использования на продакшн серверах.

Основные нововведения в версии 5.1. представлены по этой ссылке http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html

А также описаны в статье tuta_larson — Что нового в MySQL 5.1

Также немаловажно будет ознакомится со списком открытых багов для версии 5.1. — http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html


Ну и собственно ссылка на скачивание — http://dev.mysql.com/downloads/

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

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

Купил лицензию на vBulletin на два форума. На одном — летает круглые сутки (около 20000 зарегистрированных пользователей), на другом — начинает тормозить к вечеру (120000 пользователей).
Посещаемость одинаковая — 50-100 человек онлайн. Запустил на тормозящем форуме Debug Mode, оказалось что самый последний запрос занимает вплоть до 16 секунд!

UPDATE user
SET lastactivity = 1226505039
WHERE userid = 1


В повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

В MySQL есть очень полезная функциональность — кеш запросов. Кеш запросов доступен в MySQL начиная с версии 4.0.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.

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

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

Осталось совсем немного времени до выхода MySQL 5.1. В статье будут рассмотрены изменения и новые возможности этой версии.

По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

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

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

В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.

В данной статье опишу несколько приемов, которые были использованы для приложения с 4млн+ пользователей и которое имея порядка 100млн+ хитов в сутки, а в конце опишу задачу, которая решалась недавно и может быть многоуважаемое сообщество предложит мне решения этой задачи более эффективное нежели то, к которому пришел я.

Наконец нашел на бесплатном торренте эту долгожданную книгу, тут недавно её продавали за 10 вмз :-)
Но теперь каждый может скачать её бессплатно!!! :-) Что и я сделал и уже наслаждаюсь чтением этой книги.

http://www.btmon.com/Other/Unsorted/High_Performance_MySQL_2nd_Edition_Jun_2008_eBook-DDU.torrent.html

P.S. Спасибо всем, кто мне добавил кармы, я благодаря этому смог выполнить свое обещание и написать эту статью
habrahabr.ru/blogs/mysql/38907

Триггер — это хранимая процедура, которая не вызывается непосредственно, а исполняется при наступлении определенного события ( вставка, удаление, обновление строки ).
Поддержка триггеров в MySQL началась с версии 5.0.2

Что и как и как много хранит MySQL?

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

Для затравки, интересная цитата из мануала по MySQL:
«Максимальный размер записи в MyISAM составляет 65534 байтов. Каждый BLOB или TEXT-столбец засчитывается здесь как 5-9 байтов.» — как это трактовать однозначно не понятно. НО ясно что много-примного столбцов в таблицу на засунешь. «Извращенистые программисты» — будьте аккуратны (66000 столбцов вы точно создать не сможете).

UPD: Если найдете ошибку, или я что-то где-то утаил — отпишитесь в комментах, с удовольствием добавлю.

UPD1 В первую очередь (и самый лучший вариант для новичков) прочитать ОФИЦИАЛЬНЫЙ МАНУАЛ dev.mysql.com/doc/refman/5.0/en/data-types.html (спасибо Psyh за прямую ссылку), а здесь вырезка для META обработчиков данных (как в лице программистов так и в лице машинной обработки).

UPD2 В принципе, все что написано ниже, можно прочитать по адресу www.mysql.ru/docs/man/Column_types.html (за ссылку «русского перевода», спасибо artuska).

UPD3 Еще одну неплохую ссылку предоставил 4all: newcontinent.ru/h/mysqlc (материал на русском)

UPD4 Цитата из комментов от egorF:
# 14«Как главный редактор русскоязычного перевода доки на MySQL, я рекомендую в него не заглядывать — он уже сказочно морально устарел.»

Наверное каждый разработчик подходил к моменту выбора между двумя решениями одной задачи и естесвенно решающим фактором выбора является наиболее быстрый способ (по времени процесса). Так и я в ходе разработки поиска для своей CMS задался вопросом: что лучше, делать поиск по базе используя полнотекстовой индекс или с помощью оператора сравнения LIKE, имея небольшое количество информации.

Для того, чтобы ответить на свой вопрос я провел небольшой опыт: создал таблицу с четырмя полями (два из которых использовались для поиска и были проиндексированы FULLTEXT'ом) содержащую 5 000 строк. Поля по которым производился поиск содержали по 255 символов, случайно выбранных из одного большого текста. Поиск производился так же по случайным словам не короче 4-х символов.

Появилась идея собрать самые лучшие вопросы авторам MySQL,
которые приедут пообщаться на PHPConf 2008.

Предлагаю собирать их в этом топике до 15 мая.

P.S. Чур вопрос — когда MySQL кластер будет работать с HDD не предлагать ;-)

Инфраструктура крупнейшей социальной сети продолжает расти в геометрической прогрессии. На днях технический директор Facebook на конференции по MySQL огласил (видео) свежие данные: оказывается, на проект сейчас работает уже 10 000 серверов, в том числе 1 900 серверов MySQL, а обслуживают их всего два администратора баз данных.

В отличие от Google, Yahoo и Microsoft, компания Facebook не строит свои собственные дата-центры, а арендует чужие новостройки по мере необходимости. Совсем недавно к числу арендуемых добавились два новых дата-центра: в Вирджинии (октябрь 2007) и Калифорнии (февраль 2008).

Теперь становится понятно, почему IBM позиционирует новые серверы iDataPlex специально для Веб 2.0, ведь на них действительно есть спрос со стороны тех же Facebook, Yahoo, Microsoft и Amazon.

Технический директор также рассказал, что Facebook по-прежнему активно использует систему кэширования Memcached для оптимизации работы динамических веб-приложений. На сегодняшний день это самый крупный проект в мире на базе Memcached (805 серверов).

Продолжая эту тему хочу вернуться к вопросу файловой базы данных.

Интересно, что файлы в базе хранятся повторяя структуру классической ФС: файлы разбиты на блоки размером 4 Кб, хранящиеся в отдельных «blob» записях. Всего имеется 3 таблицы типа MyISAM: tree (дерево файловой системы и имена файлов), inodes (права доступа и параметры файла) и data_blocks (блоки данных).

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

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

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

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Инициативная группа MySQL AB Maria, состоящая из шести человек и возглавляемая Michael «Monty» Widenius (создатель MySQL и MyISAM), выпустила тестовую версию нового движка хранения данных Maria.