MySQLemoji, MySQL и кодировка UTF-8

Давно уже, многие годы, знал о проблеме, что комментарии в этом блоге с эмоджами не сохраняются, как и статьи, потому что MySQL ругался чем-то вроде Incorrect string value: '\xF0\x9F\x87\xB2...' for column 'text' at row 1 и записи не сохранял. Но исправить эту штуку было просто недосуг, комментируют здесь не то, чтобы сильно часто, да и то чаще боты со спамом. А вот в новой версии движка блога, которая уже фактически запущена, это было запланировано к исправлению 😁

Когда переносил блог на новый сервер, то установил там восьмую версию мускула и проверил, сохраняет или нет. Вдруг разработчики базы данных давно уже исправили этот incorrect string value, я ведь не один такой на планете с эмоджами, нас десятки и сотни тысяч, уверен, если не миллионы. Но результат не поменялся, та же ошибка. Не прокатило, штош...

MySQLПакетное обновление или batch update

Иногда возникает потребность обновить много записей в базе данных, например 3000, 7000 или 25000 штук. Видел даже веб-формы с таким количеством полей, хоть это и полное безумие :) Можно, конечно, обновить эти записи поштучно, но бомбардировать сервер базы данных запросами - плохая идея. Желательно сделать это за раз. И сделать это возможно следующим образом:

1
2
3
INSERT INTO table (`id`, `x`, `y`) VALUES
  (1, 2, 3), (4, 5, 6), (7, 8, 9)
  ON DUPLICATE KEY UPDATE `x` = VALUES(`x`), `y` = VALUES(`y`);

P.S.: Однако, как подсказывают в комментариях, есть нюанс. В случае этого самого ON DUPLICATE KEY UPDATE автоинкрементное поле для таблиц InnoDB всё равно увеличится, будто была вставка в таблицу.

PostgreSQL

PostgreSQLУстановка PostgreSQL в Mac OS X

Установка будет производится из MacPorts. Можно, конечно, воспользоваться и "родным" приложением, доступным на официальном сайте, но я лично предпочитаю порты, хотя бы из-за своевременных обновлений.

Для начала установим, собственно, PostgreSQL:

1
sudo port install postgresql93
Результат метода clear

Doctrine 2Падение производительности при импорте данных

Не в первом проекте уже сталкиваюсь с ситуацией, когда при импорте данных при помощи ORM Doctrine 2 происходит падение производительности с увеличением количества импортируемых данных. Вот и сейчас проявилась данная особенность, а заодно и обнаружилось решение, которым спешу поделиться :)

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

На последнем этапе как раз и наблюдается неприятное явление. Первые порции данных в цикле импортируются быстро, а потом становится заметно, что скорость всё падает и падает.

Вывешу скриншот из серии БЫЛО и СТАЛО, остальное под катом...

user-defined-functions

Doctrine 2Пользовательские функции DQL

Допустим, что вы используете ORM Doctrine 2 и что вам необходимо выбрать из базы некие записи, но не просто так, а по хитрому. Выборка должна осуществляться по хешу какого-то поля, значение в котором вы не хотите никому показывать из соображений безопасности. Пример, возможно, и надуманный, но не в этом суть... Короче говоря, нужно реализовать подобный запрос:

1
2
SELECT * FROM `spam` AS `s`
WHERE MD5(`s`.`secretfield`) = 'hash';

Дальнейшие действия хоть и касаются DQL и Doctrine, но будут описаны в контексте фреймворка Symfony 2. Оригинальную статью можно обнаружить в документации

MySQLMySQL Query Cache

Оставляю себе в качестве шпаргалки.

Необходимые запросы к БД для проверки работоспособности и просмотра состояния дел.

1
2
3
SHOW variables LIKE 'have_query_cache';
SHOW variables LIKE 'query%';
SHOW status LIKE 'Qcache%';