MySQL *

Столкнулся недавно с задачей показа кнопок [ВПЕРЕД] [НАЗАД] на странице просмотра. Но сложность задачи в том, что сортировка может быть по произвольному полю таблицы.

Постановка задачи:

CREATE TABLE `contacts` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name_prefix` varchar(50) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
`infix` varchar(100) DEFAULT NULL,
`surname` varchar(100) NOT NULL,
`primary_email` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

Для наглядности объясню где это все работает:
есть две страницы, работающие с этой таблицей:
— index, на ней отображаются все записи из таблицы contacts, есть фильтр и есть сортировка по столбцам
— view, просмотр текущей записи из таблицы contacts. На это странице есть кнопки [ВПЕРЕД] [НАЗАД], с учетом фильтра и сортировки заданной на странице index;
Трудность возникла в этих двух кнопках.

В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.

 

MySQL стал собственностью Oracle, есть ли альтернативы и как быстро движение вперед?.. Вроде как обобщающего обзорчика «who is who?» еще не было. Итак, обзорчик для тех кто «не в теме»

Эта заметка навеяна топиком "подсчет количества событий календаря в каждом месяце года". В ней нет ничего нового, это просто микрозаметка о возможных решениях.
Хотя задача того топика очень типична и вполне спокойно решалась обычным проходом с case или if:

SELECT
sum(
 CASE
  when t.`start_date`<'2010-02-01' and t.end_date>'2010-01-01'   then 1
  else 0
 end
)
AS jan,
sum(
 CASE
  when t.`start_date`<'2010-03-01' and t.end_date>'2010-02-01'   then 1
  else 0
 end
)
AS feb,
...
FROM test t


Но я счел нужным написать о некоторых возможностях избежать излишнюю ручную работу. Например, если нам необходимо бы было агрегировать не за год и не за два, а, скажем, за последние 5 лет помесячно. Согласитесь, в таком случае 60 строк c if'ами было бы как минимум тяжело читать.

Постановка задачи:
вывести количество событий (events) каждого месяца года.

Каждое событие имеет два поля
— start_date — дата начала события
— end_date — дата завершения события

Структура таблички с событиями календаря:

CREATE TABLE `events` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `start_date` date default NULL,
  `end_date` date default NULL,
  `created` datetime default NULL,
  `modified` datetime default NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8



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

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

Небольшой хак, позволяющий обработать «Empty set» в старых версиях MySQL (4+), в которых нет функций.

Это руководство описывает, как настроить репликацию базы данных в MySQL с использованием SSL соединение для шифрования.
MySQL репликация синхронизирует базу данных, что позволяет иметь точную копию БД на другом сервере. Все обновления БД на главном сервере автоматически реплицируются на другой сервер, что позволяет защитить базу от аппаратных сбоев. В этой статье будет показано, как реализовать репликации БД exampledb с сервера server1.example.com(ip адресом 192.168.0.100) на сервер server2.example.com(ip адресом 192.168.0.101) с использованием SSL соединения

Хотелось бы поделиться опытом по использованию MySQL с хранением данных в памяти, а не на диске. Это позволило нам сократить load average сервера, который из-за операций с диском стал сильно расти.

mysql-proxy — практически идеальное решение для тех, кому нужен дешевый шардинг без переписывания приложений, а также хостинг провайдерам, которым сложно контролировать криворуких клиентов :) но хотелось бы вынести mysql или снизить нагрузку на СУБД без лишних контактов с клиентами.

Итак, есть задача, облегчить жизнь mysql серверу. Доступное решение — master-slave репликация. Всё замечательно, когда у нас есть программисты, которые могут переписать приложение на использование нескольких серверов СУБД, но как быть, если таковых нет? Тут на помощь нам приходит mysql-proxy. Работая прозрачно для клиента, mysql-proxy умеет проксировать запросы нескольких slave & master серверов.

далее будет описание тестов

Периодически возникают ситуации, когда хочется понять, какой же процесс на сервере повинен за конкретное соединение с СУБД. К примеру, очень много соединений к базе и хочется узнать, откуда они идут. Либо, есть какие-то «тяжёлые» соединения (по которым какие тяжёлые запросы идут, которые тормозят всё).

Можно ли это вообще узнать эту информацию? Оказалось, что в этом нет ничего сложного! Однако, каждый раз руками устанавливать соответствие довольно муторно. Так почему бы не автоматизировать процесс?

Нет ничего проще!

Q:

В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?

A:

Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:

1. Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]

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

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

Upd: описанный ниже эффект проявляется только в MySQL ниже 5.1.25 — спасибо pharod.

Случайно обнаружился интересный эффект, приводивший к багу в приложении:

mysql> create table test(a int,b int);
Query OK, 0 rows affected (0.11 sec)

mysql> prepare ps from "select * from test";
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> alter table test drop column b;
Query OK, 0 rows affected (0.27 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> execute ps;
ERROR 1054 (42S22): Unknown column 'testdb.test.b' in 'field list'

Кажется, что запрос не завязан на конкретную схему таблицы и может быть выполнен и после изменения схемы. В действительности prepared statement закладывается на список колонок, который был на момент создания statement.

В реальной жизни проблема обнаружилась так: класс, отвечающий за общение с базой, кэширует prepared statements. Закэшированные statements поломались, когда потребовалось во время выполнения менять схему базы (не спрашивайте, зачем потребовалось: не всё в жизни делается так, как нам хочется). Будьте осторожнее!

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

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

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

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

Наткнулся недавно на инструмент для визуализации gource. Стало интересно как же выглядит 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).


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

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