TMBU is an ancient Aztec word, which means ‘This Might Be Useful’

Вчера я случайно удалил почти все записи из таблицы статистики просмотра видеозаписей Движущихся Картинок. Событие более чем печальное. До этого я предполагал, что восстановить удаленные записи практически невозможно. Оказалось, что можно. Если включены бинарные логи (для их включения в настройках mySQL надо указать параметр log-bin).
В результате некоторых раздумий получилась команда:
/usr/bin/mysqlbinlog --database=нужная_база_данных –start-datetime=”2008-01-01 00:00:00″ путь_ко_всем_binlog | tr “\t” ” ” | tr “\n” ” ” | tr “;”"\n” | grep “INSERT INTO \`побитая_таблица\`” > p.sql

Параметр start-datetime содержит в себе дату, с которой вынимаем логи. Можно еще указать время остановки (в моем случае это было неактуально).
Далее нужно указать не просто путь к логам, а все файлы логов (например, /var/lib/mysql/lalala-bin.*).
Несколько tr‘ов нужны потому, что запрос мой был многострочным, а надо было мне получать один запрос в одну строку.

В конечном счете в файле p.sql я получил нужные мне запросы. Единственное, что в конце строк не было точки с запятой. Это было исправное просто:
cat p.sql | sed "s/\"\)/\"\);/g" > p2.sq
Просто у меня каждый запрос оканчивался на ….”)

Когда я попытался скормить запросы mySQL’у оказалось, что из-за того, что были удалены не все записи, начались проблемы с уникальностью некоторых полей. Чтобы не копаться в дампе руками, сделал так:
cat p2.sql | sed "s/INSERT INTO/INSERT IGNORE INTO/g" > p3.sql

И уже p3.sql успешно скормил mySQL’у.

Отсюда выводы: во первых, всегда делайте бекапы (как можно чаще), и во вторых всегда включайте логирование.

P.S. Конечно же из binlog’ов можно вытащить все, что делалось с базой. И Восстановить то состояние, которое нужно.

Часто встречается ситуация, когда необходимо вручную устанавливать порядок вывода записей в некоем списке. То есть клиент должен иметь возможность двигать строчки вверх-вниз друг относительно друга. Некоторые "программисты" изобретают для этого сложнейшие велосипеды. На самом же деле сделать это очень просто. Просто создаем дополнительное поле `customorder`, которое по умолчанию равно `id` (в случае, усли `id` не auto_increment, можно его ставить в (MAX(`customorder`) + 1)). Затем используем вот такую простую функцию:

И да, я знаю, что это можно сделать меньшим количеством запросов. Но так нагляднее :).

Несколько раз натыкался на эту проблему, но только сегодня полноценно ее решил. Проблема проста: есть запрос с несколькими JOIN'ами. При выполнении запроса толком не используются индексы. В результате все ужасно тормозит.
Запрос примерно такой:

Понятно, что все может быть сложнее, но для примера сойдет.
Итак, что же надо сделать, чтобы запрос работал максимально быстро (при условии, что запрос и таблицы построены грамотно)?

1. Создать индекс по каждому из полей, используемых в WHERE и JOIN. Отдельно по каждому.
2. Убедиться, что в WHERE указано максимально жесткое условие дабы сократить диапазон выборки.
3. А теперь - внимание! Убедиться, что у `a`.`field1` и `b`.`field2` одинаковый collation!

Комментарий по последнему пункту: В моем случае у одного поля был latin1_swedish_ci, у второго - utf8_general_ci. Вроде как по данным выходило правильно. Но запрос работал очень медленно, порядка 3 секунд (использовались три таблицы с большим количеством записей - ~100,000, ~30,000 и ~3,000). После применения пункта номер один и особенно пункта номер три запрос стал выполняться за 0.1 (одну десятую!) секунды.

В MS SQL отсутствует LIMIT в SELECT'е. Это поразительно и глупо, но это так. И после MySQL это невероятно раздражает. Поэтому было найдено решение проблемы. Сравнительно медленное, но зато работающее не только в новых версиях MS SQL (где есть row_number(), облегчающий жизнь). Итак, для того, чтобы сделать то же, что в MySQL делает следующий запрос:

в MS SQL надо написать:

База именин для латвийских имен. Формат довольно простой и грубый, но использовать можно. Поле `date` это дата в формате [m]mdd, `name` - это имя в латышском написании, а `simplename` - упрощенная версия имени, в которой длинные буквы продублированны, а смягченные заменены на их твердые аналоги. Дамп c MySQL 5.0 сервера.
(more...)