MySQL *

В MySQL есть такой специальный режим, предназначенный для введения в базу неправильных данных. Например, чтобы вместо 20000000000 вставлять в INT-поле 2147483647. Или наполнять базу несуществующими датами. Или обрезанными строками. Ну или мало ли для чего этот режим может тебе пригодится.

Режим этот называется «обычный режим».

Офсайт СУБД MySQL вчера взломан двумя злоумышленниками через банальное SQL injection. По ссылке опубликован отчёт о взломе и выложены некоторые части внутренней структуры базы данных, дамп паролей и т.д.

Vulnerable Target : mysql.com/customers/view/index.html?id=1170
Host IP : 213.136.52.29
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web

Хуже всего, что пароли юзеров уже пошли в разработку, в том числе уже расшифрован пароль директора по разработке продуктов MySQL (всего четыре символа), пароли многочисленных админов на форуме и т.д. Так что если у вас есть аккаунт на MySQL.com, то рекомендуется срочно сменить данные регистрации.

Кстати, те же два злоумышленника одновременно взломали и Sun.com тем же способом.

В ходе разработки сервиса по расчете статистики по управлению запасами для интернет-магазинов возникла задача быстро организовать импорт/экспорт таблиц между разными MySQL серверами. Поскольку надо было сделать просто и прозрачно — оптимизация будет впереди — решил воспользоваться авторскими рекомендация из документации по MySQL 5.0.

Привет, Хабрачитатель!
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.

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

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

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