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 серверов).

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

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

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

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

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

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

Только сейчас наткнулся на новость о том, что Sun Microsystems купила MySQL AB за 1 миллиард долларов. Наверное это будет серьезным толчком в развитии этой СУБД. А вы как считаете, что за этим последует?

Тысячи серверов в собственных дата-центрах Facebook с трудом выдерживают нагрузку. Каждую неделю на сайте регистрируется почти два миллиона новых пользователей вдобавок к имеющимся десяткам миллионов. Все они проводят на сайте в среднем по нескольку часов и загружают сотни страниц в день, что создаёт немалые проблемы для инженеров. Один из программистов Facebook рассказывает в корпоративном блоге, с чем приходится иметь дело.

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

Впрочем, инженеры Facebook эту ситуацию предвидели заранее и уже давно начали обустройство нового дата-центра в Вирджинии, который сейчас введён в строй. Судя по всему, это далеко не последний дата-центр компании Facebook.

Значится так — есть задача вытянуть данные из таблицы mysql в простенький csv файлик, дабы его открыть быстренько в excel. Зачем белым людям нужна такая магия — мне никогда не понять, но раз заказчик попросил, то я сделал. Итак, отдаёмся во власть консоли и пишем:
mysqldump -u [USER_NAME] -p "--where=[WHERE]" "--fields-terminated-by=," "--tab=./" [DB_NAME] [TABLE] > [TABLE].txt

Вот и вся любовь (на выходе получим два файла — один с SQL и второй с CSV)

p.s. директория в которой выполняется эта команда должна быть открыта для записи, иначе оно ругаться будет ;)

Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.

Мы уже рассказывали, на чём работает MySpace и как устроены дата-центры Google, а теперь посмотрим на более мелкие проекты, такие как digg. Здесь нет ничего особо уникального и сделанного «по спецзаказу», как в первых двух случаях, но всё равно интересно.

В момент запуска проект размещался на единственном Linux-сервере с Apache 1.3 и PHP 4.x. Для управления базами данных использовались MySQL 4.0, таблицы MyISAM и встроенный поиск MySQL. Разработчики специально старались использовать как можно больше продуктов open source, чтобы гарантировать быстрое развитие проекта без финансовых затруднений. Кроме вышеперечисленных, нашли применение свободные пакеты ImageMagick, Ispell, prototype/scriptaculous и другие. Вскоре к одному серверу добавился другой и начался бурный рост проекта.

Это случалось с каждым из нас при разработке веб-сайтов или приложений, использующих MySQL в качестве базы данных. Производительность внезапно сильно падала, и вы не имели понятия, почему это случилось. Этому могут быть причиной многие факторы (сильная загрузка CPU, нехватка дискового пространства, или слабая пропускная способность канала), но также это может быть и неоптимизированный запрос, выполняемый намного дольше, чем должен.

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