MySQL *

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

Давайте рассмотрим простой пример.
Есть таблица:

CREATE TABLE IF NOT EXISTS shop (
  id INT NOT NULL AUTO_INCREMENT,
  article INT(4) ZEROFILL NOT NULL,
  dealer VARCHAR(45) NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (id))
ENGINE = InnoDB;

Необходимо для всех article найти dealer с максимальной ценой.

Для этой задачи существует несколько очевидных и простых решений, но я знаю одно из них, которое значительно превосходит все остальные.
Сталкивались с этой задачей? Хотите увидеть новый способ ее решения? Прошу под кат.

Начиная с версии 5.1 в MySQL реализована поддержка динамически подключаемых плагинов. А дистрибутив содержит примерный скелет кода под названием – example. Он описывает интерфейс и структуру базового обработчика – handler, копия которого создается отдельно для каждого соединения с БД. Также ему передаётся указатель на дескриптор таблицы TABLE *table и вспомогательный вектор TABLE_SHARE *share, используемый для синхронизации с другими обработчиками. Разработку плагина можно осуществлять по модульному принципу, реализуя только необходимые функции в первую очередь и закрывая заглушками более сложные операции.
Поскольку шаблон example описывает только интерфейс и не выполняет никаких операций, то в этом примере мы добавим в него реализацию CRUD-операций на основе одно-связного списка.

Всем привет, хабрачитатели!

Это статья про очередной хабрапарсер.
В конце сентября я читал какую то статью и там опять были слова «стартап», «инновации», «javascript», «фреймворк».
Казалось что в каждом посте они есть. И я решил это проверить. Подробности под катом.

Мне часто приходилось сталкиваться с нодовыми интерфейсами в программах. Начиная с музыкальных модульных приложений, заканчивая пакетами для создания трехмерной графики.

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

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.

Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и длительность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.

Выводы из условия:

— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.

Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.

Проект phpMyAdmin появился на свет 9 сентября 1998 года, когда Тобиас Ратшиллер (Ratschiller) выпустил версию 0.9.0. За прошедшие полтора десятилетия phpMyAdmin превратился в один из основных инструментов для администрирования MySQL и других MySQL-подобных баз данных, с гордостью пишут разработчики.

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

К созданию phpMyAdmin причастны 669 разработчиков, а основная группа разработчиков выросла с 1 до 9 человек.

Можно ли уместить исходники MySQL клиента на 1 страничке формата A4? Оказывается, если 8 кеглем (в принципе читаемо) и после обфускации, то можно! А если нормальный код без обфускации и 10 кеглем, то таки нельзя: надо целых 6 страничек.

В ходе работы над всяким у меня тут случайно получился крохотный, но работающий MySQL клиент размером чуть больше 1000 строк. Стало интересно, насколько компактнее можно сделать. Потратил половину воскресенья, изолировал и минимизировал код. В результате появился nanomysql, CLI клиент для MySQL, полные исходники которого занимают чуть менее 380 строк и примерно 10500 байт, и при этом компилируются и работают под Linux, Windows, MacOS. Написано на C++ с абсолютным минимумом STL.

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

Хорошей пятницы, Хабр!

Как многим известно, отдельные баги в MySQL не закрываются годами. Но все еще открытому багу #20786 «mysqldump always includes AUTO_INCREMENT» повезло больше других — на свое семилетие он хотя бы получил самый настоящий праздничный торт!




Страница бага

Один из основателей проекта MySQL, на данный момент руководитель проекта MariaDB Ульф Майкл Видениус (известный также под ником Монти), в интервью ITwire говорит о том, что Oracle провалила попытку сделать MySQL успешным продуктом, потому что компания не понимает открытую модель разработки программ.

«Это не в их ДНК», — добавил Монти. — «Они пытаются вести открытый проект в той же самой манере, в которой они разрабатывают свои закрытые продукты, и это большая ошибка».

Недавно Red Hat — компания, стоящая за разработкой наиболее популярного дистрибутива Linux в бизнес-секторе — объявила о том, что в готовящейся к выпуску седьмой версии дистрибутива MySQL будет заменён его ответвлением — MariaDB. За разработкой MariaDB в свою очередь стоит Монти и основанная им компания Monty Program Ab. Ранее под крылышко компании Монти также перешла компания SkySQL, вместе с другим со-основателем MySQL Дэвидом Аксмарком, который работал там как технический директор. Третий со-основатель MySQL — Алан Лариссон — также работает с Монти, помогая ему по мере необходимости своим советом и делом.

Монти сказал, что главной причиной, по которой всё больше и больше людей и компаний стали искать альтернативу MySQL, послужил в большей степени тот факт, что Oracle ясно показала своё нежелание играть по принятым правилам с сообществом разработчиков. Объясняя своё мнение, он добавил, что «выделение открытого ядра MySQL, удаление тестов из исходных кодов (большей частью для того, чтобы усложнить жизнь проектам, основанным на его кодовой базе) и создание таких условий, при которых никто не может разрабатывать MySQL с теми же привилегиями, какие есть у Oracle», это всё послужило причиной сложившейся ситуации.

Разработчики MariaDB случайно заметили, что в промежутке от MySQL 5.5.30 к MySQL 5.5.31 в проекте изменился текст лицензии во всех файлах в каталоге man/.

Вместо прежнего краткого текста «Эта документация является свободным программным обеспечением, вы можете распространять и/или изменять её только под условиями лицензии GNU General Public License, как опубликовано Фондом свободного ПО; версия 2 лицензии» теперь длинное описание, начинающееся со слов: «Это программное обеспечение и сопутствующая документация распространяются под лицензионным соглашением, которое содержит ограничения на использование и разглашение и защищена законами об интеллектуальной собственности».

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

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

При разработке современных веб-приложений сложно недооценить пользу от использования систем контроля версий. Применительно к файлам разрабатываемого продукта, мы способны отследить любые этапы производства в любой момент, начиная с первой ревизии. Инструменты, помогающие нам в этом, на сегодняшний день популяризированы, считаются хорошим тоном при разработке, а во многих случаях успешное производство без их применения невозможно в принципе. А какие возможности мы имеем, когда возникает необходимость проследить изменения не в файлах, а в базах данных проекта? Под катом я поделюсь информацией о существующих средствах, с которыми мне пришлось ознакомиться.

Разбираясь как работает та или иная CMS приходится использовать различные инструменты, облегчающие работу.
Наиболее интересная тема — это работа с баз(ой|ами) данных. Естественно для изучения запросов и результатов запросов нужно использовать что-то универсальное. Что-то, что будет работать стабильно как с известным движком, так и с самописной системой.
Предположим у вас оказалась система управления контентом и вам необходимо посмотреть как реализовано добавление новых пользователей или смена паролей.

Большинство инструментов позволяющих мониторить работу с БД являются платными [раз, два]. Я хотел что-то более легкое и удобное, поэтому выбрал mysql-proxy. Хотя возможности утилиты гораздо шире чем мне требуется, я опишу лишь основное. Работает как под Windows, так и под Unix системами.

Цель данного поста — помочь начинающему разработчику быстро освоится и спроектировать простенькую базу с помощью инструмента для визуального проектирования баз данных MySQL Workbench от компании Oracle и получить её ER-модель и SQL-дамп.

Что я успел понять про MySQL за несколько лет его разработки:

• развивать не ломая обратной совместимости его нельзя
• MySQL со сломанной обратной совместимостью никому не нужен.

Я опишу две серьёзные проблемы ДНК MySQL, с которыми косвенно сталкивается любой пользователь MySQL 5.1 и 5.5 (насчёт 5.6 не проверял, но не думаю, что этот момент поменялся).

Как вообще MySQL работает?

5 февраля компания Oracle анонсировала выпуск стабильного релиза MySQL версии 5.6. В новой версии проделана огромная работа. Основные усилия были направлены на повышение производительности, масштабируемости и гибкости. Масштабным по значимости изменениям подвергся движок InnoDB.

К ключевым улучшения можно отнести: поддержка средств полнотекстового поиска, возможность доступа к данным через memcached API, увеличена производительность работы при интенсивной записи данных, а также увеличена масштабируемость при обработке большого числа одновременных запросов.

Очень часто в интернете встречаюсь со статьями, в которых приводят кучу примеров с якобы странным поведением MySQL по сравнению с другими БД. Чтобы стало понятно, о чём я говорю, приведу несколько примеров:
1. Деление на ноль возвращает NULL вместо ошибки
2. Выход за диапазон допустимых значений неявно приводит число к допустимому значению, а не к ошибке и откату транзакции
3. Вставка неверного типа данных также приводит к неявному преобразованию и успешному выполнению операции
Таких примеров я могу привести огромное число, но цель статьи не сделать очередное собрание высосанных из пальца примеров, а объяснить, почему происходит то или иное действие. Вся эта мистика MySQL давно описана в документации и легко объяснима, в чём вы сможете убедиться сами, прочитав статью до конца.
Для меня эта первая статья на хабре, поэтому я старался писать дотошно подробно. Уверен, что она будет полезна всем, кто работает с MySQL. Большую помощь в написании статьи оказала подготовка к сдаче на сертификат разработчика MySQL, а точнее книга «MySQL Certification Study Guide».
Итак, мой друг, начнём!

Все мы знаем про то, что QUERY CACHE бывает очень полезен, если вам необходимо оптимизировать часто повторяющиеся запросы к базе данных, при условии низкого числа DML операций (если вы совсем не знакомы с данной функциональностью, перевод официальной документации по настройке этой структуры базы данных можно почитать тут). При настройке параметров кэширования запросов на сервере часто встает вопрос, а что же именно содержится в QUERY CACHE'е на данный момент. Поиск ответа на этот вопрос в свое время поставил меня в тупик. Единственный дельный ответ, который я посчитал в то время абсолютно верным, я нашел тут. Ответ гласил буквально следующее:

there is no way to find what queries are now cached

т.е. данного способа не существует. Лишь спустя некоторое время я понял, что это совсем не так, и существует вполне легальный способ получения содержимого данной структуры БД без патчинга исходных кодов. Этот способ — написание небольшого плагина для INFORMATION_SCHEMA.