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-страницы.

В ноябре этого года, в Портланде, США прошла конференция OpenSQL Camp посвященная опенсорс СУБД.
Совершенно случайно наткнулся на видео докладов и спешу ими поделиться. Общий уровень конференции, как мне показалось, достаточно высок, так что советую посмотреть. Часть видео, к сожалению, в плохом качестве. Все презентации, конечно же, на английском.

Возникла у меня некоторое время назад нужда в создании мгновенных бекапов базы данных mysql. Желание существовало уже давно, но как-то до сих пор вроде нормально жилось с репликацией и бекапом со slave. Но случаи бывают разные, и возможность снять мгновенный снимок с файловой системы master-сервера может очень сильно облегчить жизнь. Я понял, что нужен мне snapshot. А там где snapshot, там полуавтоматически появляется на горизонте ZFS. Кроме того в ней еще есть некоторые вкусности, которые на данный момент мне вроде и не особо нужны, но в принципе их наличие может значительно скрасить жизнь.

Сам процесс получения снимка файловой системы я пока оставляю в стороне, но пытаюсь получить некоторое представление о ZFS в сравнении с UFS в моих условиях. Недавно я публиковал на хабре перевод материала от John David Duncan. Там описано все достаточно вкусно, но надо пробовать самому.

Я попробовал…

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

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

На хабре проскакивали статьи про PHP и Javascript beautifier'ы, но для SQL запросов я тут ничего не нашёл. Постараюсь исправить этот пробел.

Наиболее популярный SQLinForm. Единственный минус этого решения является требование Java Runtime.

Менее «фичастый» и более удобный для работы Instant SQL Formatter. Пример работы можно посмотреть здесь.

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

Доброго времени суток.

Очень хотелось поднять вопрос о древовидных структурах в MySql. А конкретно о выборках и хранении данных…
Пользователям Oracle и PostgresSQL живется хорошо, в этих БД есть встроенные средства выборки рекурентных данных (см. Иерархические (рекурсивные) запросы).
Пользователям Mysql приходится работать уже с тем, что есть, то есть работа на стороне клиента.
Поскольку эта тема не однократно поднималась, то я попробую рассказать о конкретной задаче и способе её решения.

Так получилось, что я довольно давно не работал с 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% что они актуальны и по сей день, и будут актуальны еще долго. Сложными их назвать нельзя, но и очень простыми тоже (в зависимости от уровня подготовки конечно).

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.

Статья о том, как избежать путаницы с датами, хранимыми в mysql.
Эти путаницы возникают по двум причинам:
1. Разные территории нашей планеты имеют разный сдвиг времени.
2. Некоторые страны переходят на летнее время и обратно(карта со странами, переходящими на летнее время).

Многие решают эти проблемы по-разному. Кто-то делает сдвиг даты в SQL запросах, кто-то в php. Кто-то хранит даты в TIMESTAMP, кто-то в DATETIME. Я переискал много источников, но нигде не нашел верного решения данной проблемы на русском. В родной документации по mysql нашел информацию о том, как добиться корректной автоматической конвертации TIMESTAMP в локальное время, но тут тоже свои подводные камни.

Если в php настройка временной зоны делается просто, в mysql возникают сложности, особенно, если доступ к mysql серверу вам ограничен и там еще не установлены некоторые таблицы.

Компания Sun Microsystems и Образовательный Центр i∙klass и приглашают вас на семинар «Производительность MySQL».

Докладчик:
Дмитрий Кравчук, Principal Benchmark Engineer, Sun Microsystems, Париж, Франция

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

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