Самый простой вариант – совершенно случайная дата:

mysql> SELECT FROM_UNIXTIME(RAND() * 2147483647) AS `rand`;
+---------------------+
| rand                |
+---------------------+
| 1998-04-01 21:42:48 |
+---------------------+
1 ROW IN SET (0.00 sec)

Попробуем ещё раз?

mysql> SELECT FROM_UNIXTIME(RAND() * 2147483647) AS `rand`;
+---------------------+
| rand                |
+---------------------+
| 2028-03-21 22:44:43 |
+---------------------+
1 ROW IN SET (0.00 sec)

Окей, зачем умножать на 2147483647? (ещё не догадались?! Ну тут всё просто, как 2 копейки: 2147483647 это самый большой SIGNED INT32 и по совместительству писарчук самый последний распоследний таймштамп. Проверяется это так (ежели не верите):

Так ещё работает:

mysql> SELECT FROM_UNIXTIME(2147483647) AS `rand`;
+---------------------+
| rand                |
+---------------------+
| 2038-01-18 19:14:07 |
+---------------------+
1 ROW IN SET (0.00 sec)

А если добавим хоть секундочку (2147483648) – уже работать не будет:

mysql> SELECT FROM_UNIXTIME(2147483648) AS `rand`;
+------+
| rand |
+------+
| NULL |
+------+
1 ROW IN SET (0.01 sec)

Таким образом, функция RAND() даёт нам случайное значение в диапазоне от 0 до 1 и умножая его на максимально возможный таймштамп мы получим случайную дату в диапазоне от 1969 до 2038 гг. Но что же нам делать, если требуется дата в некотором строго определённом периоде?

Случайная дата 2011го года

Получается вот так:

mysql> SELECT FROM_UNIXTIME(RAND() * (1325275200 - 1293825600) + 1293825600) AS `the_date`;
+---------------------+
| the_date            |
+---------------------+
| 2011-04-27 05:01:04 |
+---------------------+
1 ROW IN SET (0.00 sec)

Так круто, что хочется попробовать ещё раз

mysql> SELECT FROM_UNIXTIME(RAND() * (1325275200 - 1293825600) + 1293825600) AS `the_date`;
+---------------------+
| the_date            |
+---------------------+
| 2011-08-15 12:54:51 |
+---------------------+
1 ROW IN SET (0.01 sec)

А чо энто было то?

Когда нам нужно зафиксировать диапазон, между start и end датами, и мы имеем случайное значение от 0 до 1 – требуется вычесть из конечного таймштампа начальный end - start, что даст искомый интервал в секундах и “двинуть” интервал в начало периода. Т.о. наша супер-формула выглядит вот так:

(end - start) * RAND + start

Ну и для того чтобы высвободить вам побольше времени для Angry Birds (или чего-то подобного), а также не морщить лоб, пытаясь в уме переводить DATETIME в TIMESTAMP – мы воспользуемся функцией UNIX_TIMESTAMP:

mysql> SELECT
    -> UNIX_TIMESTAMP('2011-01-01') AS START,
    -> UNIX_TIMESTAMP('2011-12-31') AS END;
+------------+------------+
| START      | END        |
+------------+------------+
| 1293825600 | 1325275200 | 	
+------------+------------+
1 ROW IN SET (0.00 sec)

Оригинал для перевода взял тут: http://www.phpied.com/random-mysql-date/

Перевод статьи про анализ сложных MySQL запросов:

Для данной статьи возьмем запрос из статьи про ORDER BY RAND, так он достаточно интересен для рассмотрения различных аспектов запросов. Он содержит:

• Подзапросы;
• Объединения;
• Особые случаи;
• JOIN’ы
• Сортировку ORDER BY + LIMIT

Если вы хотите понять как запрос был создан, посмотрите оригинальную статью ORDER BY RAND.

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

Рассмотрим результаты EXPLAIN запроса:

> EXPLAIN EXTENDED
(SELECT r1.name FROM random AS r1
   JOIN (SELECT (RAND() *
                (SELECT MAX(id) FROM random)) AS id
        ) AS r2
  WHERE r1.id >= r2.id
  ORDER BY r1.id ASC
  LIMIT 1)
UNION ALL
(SELECT r1.name FROM random AS r1
   JOIN (SELECT (RAND() *
                (SELECT MAX(id) FROM random)) AS id
        ) AS r2
  WHERE r1.id >= r2.id
  ORDER BY r1.id ASC
  LIMIT 1);

И собственно сами результаты:

+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+
| id | select_type  | table      | type   | possible_keys | key     | key_len | ref  | rows    | filtered | Extra                        |
+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+
|  1 | PRIMARY      | <derived2> | system | NULL          | NULL    | NULL    | NULL |       1 |   100.00 | Using filesort               |
|  1 | PRIMARY      | r1         | ALL    | PRIMARY       | NULL    | NULL    | NULL | 1000000 |   100.00 | Using where                  |
|  2 | DERIVED      | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | No tables used               |
|  3 | SUBQUERY     | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | Select tables optimized away |
|  4 | UNION        | <derived5> | system | NULL          | NULL    | NULL    | NULL |       1 |   100.00 |                              |
|  4 | UNION        | r1         | range  | PRIMARY       | PRIMARY | 4       | NULL |  153726 |   100.00 | Using where                  |
|  5 | DERIVED      | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | No tables used               |
|  6 | SUBQUERY     | NULL       | NULL   | NULL          | NULL    | NULL    | NULL |    NULL |     NULL | Select tables optimized away |
| NULL | UNION RESULT | <union1,4> | ALL  | NULL          | NULL    | NULL    | NULL |    NULL |     NULL |                              |
+----+--------------+------------+--------+---------------+---------+---------+------+---------+----------+------------------------------+

Запрос состоит из 2х SELECT’ов и UNION’а. Результат UNION получается за счет объединения id 1 и 4 (union1,4), что можно увидеть в последней строке.

Id 1 это JOIN между временной таблицей derived2 и random. Поскольку id остается неизменным, запрос как правило является частью JOIN. deriverd2 это результат id 2 (DERIVED) с его подзапросом id3.

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

• MAX(id) может быть оптимизирован в данном случае последним значением индекса. Это единичный поиск, который не требует ни сортировки, ни группировки… (id 3 and 6)
• Мы вынесли рассчет RAND() * MAX(id) в подзапрос, чтобы быть уверенными, что оптимизация MAX() действительно имеет место (вычисляется один раз // прим. пер.) (id 2 and 5)
• Мы использовали ORDER BY + LIMIT чтобы оптимайзер выполнил INDEX READ и остановился после обнаружения одной строки. (id 1 and 4)

стоимость выборки

Мы можем доказать нашу теорию при помощи проверки SHOW STATUS.

> FLUSH STATUS;
> SELECT ...;
> SHOW SESSION STATUS;

Команда FLUSH STATUS сбрасывает значения счетчиков для текущей сессии, команда SHOW SESSION STATUS отображает счетчики:

| Select_full_join                  | 0         |
| Select_full_range_join            | 0         |
| Select_range                      | 2         |
| Select_range_check                | 0         |
| Select_scan                       | 1         |

Мы имеем 2 range scans (ORDER BY + LIMIT), по одному для каждой части нашего UNION и 1 table scan для чтения результатов UNION и отправки их на клиент.

Для того чтобы доказать что мы не используем дорогую сортировку – проверим счетчики Sort-*:

| Sort_merge_passes                 | 0         |
| Sort_range                        | 0         |
| Sort_rows                         | 0         |
| Sort_scan                         | 0         |

Таблица для тестов содержит 1 миллион строк, но мы читаем всего несколько штук из них:

## наши временные таблицы:
| Created_tmp_tables                | 3         | 2 вторичные таблицы + UNION RESULT
## тут мы пишем только во временные таблицы в памяти
| Handler_write                     | 4         | (1 строка + 1 строка) для вторичных таблиц + 2 строки для результата UNION
## MAX(id) выполняет Index-lookup для _last_ id
| Handler_read_first                | 2         |
## ... и мы ищем одну строку для random-id внутри JOIN
| Handler_read_key                  | 2         |
| Handler_read_next                 | 0         |
| Handler_read_prev                 | 0         |
| Handler_read_rnd                  | 0         |
## все чтения из временных таблиц не индексированы
| Handler_read_rnd_next             | 5         |
## виртуальная стоимость запроса ... "foobars"
| Last_query_cost                   | 10.499000 |

а что насчет “старого доброго” ORDER BY RAND?

Ради прикола посмотрим на классический запрос еще раз:

> FLUSH STATUS;
> SELECT name FROM random ORDER BY RAND() LIMIT 1;
> SHOW SESSION STATUS;
> EXPLAIN SELECT name FROM random ORDER BY RAND() LIMIT 1;
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra                           |
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+
|  1 | SIMPLE      | random | ALL  | NULL          | NULL | NULL    | NULL | 1000000 | Using temporary; Using filesort |
+----+-------------+--------+------+---------------+------+---------+------+---------+---------------------------------+

В общем дело было так: ALL rows – все строки – сортируются во временной таблице и озвращается лишь одна!

## цена запроса "несколько" выше :)
| Last_query_cost                   | 210744.186500 |
## у нас используется только одна временная таблица, с намного бОльшим числом строк
| Created_tmp_tables                | 1             |
| Handler_write                     | 1349207       |
## Выполняется один ГИГАНТСКИЙ table-scan для заполнения временной таблицы
| Select_scan                       | 1             |
| Handler_read_rnd_next             | 2349209       |
## и тяжелейшая сортировка
| Sort_merge_passes                 | 19            |
| Sort_range                        | 0             |
| Sort_rows                         | 2             |
| Sort_scan                         | 1             |

Источник: http://jan.kneschke.de/projects/mysql/analyzing-complex-queries/

Перевод как водится мой. Также хочу отметить что не смотря на небольшой объем текста перевод выдался тяжелым с точки зрения понимания. Если видите что я где-то накосячил или не прав – отпишите в комметариях или в личку. 10nx )

Да, лично для меня статья оказалось полезна в плане использования счетчиков и интерпретации их значений. Надеюсь и вам тоже.

• Наличие списка исключений (т.е. бэкапим все кроме…)
• Получение списка всех БД из MySQL (не надо добавлять вновь созданные базы к бекапу)
• Создание директории под бэкап вида “…/YYYY/mm/dd/HH-MM/”
• Бэкап каждой базы в отдельный файл вида “YYYY-mm-dd.HH-MM.databasename.backup.sql” (mysqldump бэкапит все в один файл)
• Архивирование бэкапа в тарбол
• Зачистка .sql

Собственно к написанию скрипта меня сподвигло именно то что mysqldump бэкапит все что ему сказано в один файл (если требуется восстановить одну базу, то попробуй ее выцарапай из общего дампа…), а создавать отдельную строку для бэкапа всякой новой БД геморно (об этом как минимум надо вспомнить!).

В общем если интересно – прошу под кат:

Собственно сам скрипт

#!/bin/bash
 
##
# MySQL backup utility
# @author dmitry.bykadorov@gmail.com
##
 
# current date
DATE=`date +%Y-%M-%d`
 
# y/m/d/h/m separately
YEAR=`date +%Y`
MONTH=`date +%m`
DAY=`date +%d`
HOURS=`date +%H`
MINUTES=`date +%M`
 
# database credentials
DBUSER=""
DBPASS=""
DBHOST=""
 
# create list of databases
mysql -h $DBHOST -u $DBUSER -p$DBPASS -e "show databases;" > /tmp/databases.list
 
# create backup dir (e.g. ../2011/01/01/04-00)
BACKUP_DIR=/home/backups/mysql/$YEAR/$MONTH/$DAY/$HOURS-$MINUTES
mkdir --parents --verbose $BACKUP_DIR
 
# excludes list (Database is a part of SHOW DATABASES output)
EXCLUDES=( 'Database' 'information_schema' )
NUM_EXCLUDES=${#EXCLUDES[@]}
 
for database in `cat /tmp/databases.list`
do
  skip=0
 
  let count=0
  while [ $count -lt $NUM_EXCLUDES ] ; do
    # check if this name in excludes list
    if [ "$database" = ${EXCLUDES[$count]} ] ; then
      let skip=1
    fi
    let count=$count+1
  done
 
  if [ $skip -eq 0 ] ; then
    echo "++ $database"
    # now we can backup current database
    cd $BACKUP_DIR
    backup_name="$YEAR-$MONTH-$DAY.$HOURS-$MINUTES.$database.backup.sql"
    backup_tarball_name="$backup_name.tar.gz"
    `/usr/bin/mysqldump -h "$DBHOST" --databases "$database" -u "$DBUSER" --password="$DBPASS" > "$backup_name"`
    echo "   backup $backup_name"
    `/bin/tar -zcf "$backup_tarball_name" "$backup_name"`
    echo "   compress $backup_tarball_name"
    `/bin/rm "$backup_name"`
    echo "   cleanup $backup_name"
  fi
done
 
`/bin/rm /tmp/databases.list`
 
echo "done!"

Можете его свободно:

• использовать (никаких гарантий я вам конечно же не даю – на свой страх и риск )))
• модифицировать (например добавить выгрузку бэкапа на другой сервер или на Amazon S3 )))
• критиковать ))

P.S. Если таки будете использовать – не забудьте подставить ваши mysql credentials ))

Интересно? Тогда вам под кат:

Немного подробностей можно найти тут: http://bugs.mysql.com/bug.php?id=55556

А решение в общем-то имеется весьма топорное – переименовать базу. Тут у нас есть два варианта:

- dump/restore – т.е. сделать дамп старой базы, создать новую и влить туда дамп.

Однако, если вы озаботились кешированием, то база у вас явно не на 1000 строк и такое решение займет прилично времени.

Можно “скопировать” mysql базу более простым способом: заменой схем.

Алгоритм  в принципе тоже не сложен:

- CREATE DATABASE `newdb`; // конечно же теперь без дефисов! )

- для каждой таблицы в старой БД выполнить ALTER TABLE `old-db`.`tbl_name` RENAME TO `newdb`.`tbl_name`; (фактически подменяем схему и все).

- ну и DROP DATABASE `old-db`;

Замечание: при переименовании таблиц надо быть аккуратнее с триггерами. Я бы предложил перед переименованием делать DROP на триггер и пересоздавать его после переименования в новой схеме – иначе рискуете нарваться на ошибку.

Как-то так на этот раз… )

p.s. Спасибо Сергею Караткевичу за “наводку” на данный баг )

Довольно часто у нас возникает потребность выборки случайных данных из mysql базы данных. Как правило времени нет и используется самая простая конструкция вида SELECT [что-то] FROM [где-то] WHERE [то и сё] ORDER BY RAND(). Эта конструкция работает на ура. Но вот прототип выезжает на продуктовые сервера и такой милый сердцу запрос вдруг начинает выпадать в топы медленных логов. Ниже будут рассмотрены несколько возможностей для оптимизации этого запроса по нарастанию их эффективности:

В первых примерах мы полагаем что ID стартует с номера 1 и в ID нет разрывов между 1 и максимальным ID.

#1. Передать всю работу в приложение

Мы можем тупо слить всю работу по определению случайного номера в приложение.

SELECT MAX(id) FROM random;
## генерируем случайный ID в приложении
SELECT name FROM random WHERE id = id_из_приложения

Так как MAX(id) == COUNT(id) нам всеголишь нужно сгенерировать случайное число между 1 и MAX(id), передать его в запрос к БД и получить свою случайную строку.

Первый SELECT у нас фактически NO-OP и он оптимизирован по самое “не балуйся”. Второй запрос это eq_ref по константе и он тоже очень быстр.

#2. Делаем всю работу на стороне базы данных

Но настолько ли необходимо делать случайные выборки через приложение? Может стоит вынести “грязную” работу на сторону базы данных (прим. пер.: на самом деле первый способ это практически сферический конь в вакууме – большинство реальных задач будет выходить за рамки его применимости)

# генерируем случайный ID
> SELECT RAND() * MAX(id) FROM random;
+------------------+
| RAND() * MAX(id) |
+------------------+
|  689.37582507297 |
+------------------+

упс, это число типа double, а нам нужен int

> SELECT CEIL(RAND() * MAX(id)) FROM random;
+-------------------------+
| CEIL(RAND() * MAX(id))  |
+-------------------------+
|                1000000  |
+-------------------------+

уже лучше, но что насчет скорости?

> EXPLAIN
SELECT CEIL(RAND() * MAX(id)) FROM random;
+----+-------------+-------+-------+---------+-------------+
| id | select_type | table | type  |   rows  | Extra       |
+----+-------------+-------+-------+---------+-------------+
|  1 | SIMPLE      |random | index | 1000000 | Using index |
+----+-------------+-------+-------+---------+-------------+

index scan? похоже мы потеряли оптимизацию MAX()

> EXPLAIN
SELECT CEIL(RAND() * (SELECT MAX(id) FROM random));
+----+-------------+-------+------+------+------------------------------+
| id | select_type | table | type | rows | Extra                        |
+----+-------------+-------+------+------+------------------------------+
|  1 | PRIMARY     | NULL  | NULL | NULL | No tables used               |
|  2 | SUBQUERY    | NULL  | NULL | NULL | Select tables optimized away |
+----+-------------+-------+------+------+------------------------------+

Ура! Простой подзапрос возвращает нашу потерянную производительность!

Окей, теперь мы знаем как сгенерировать случайный ID, теперь надо получить и соответствующую ему строку:

> EXPLAIN
SELECT name
FROM random
WHERE id = (SELECT CEIL(RAND() *
(SELECT MAX(id)
FROM random));
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
|  1 | PRIMARY     | random | ALL  | NULL          | NULL | NULL    | NULL | 1000000 | Using where                  |
|  3 | SUBQUERY    | NULL   | NULL | NULL          | NULL | NULL    | NULL |    NULL | Select tables optimized away |
+----+-------------+--------+------+---------------+------+---------+------+---------+------------------------------+
> show warnings;
+-------+------+------------------------------------------+
| Level | Code | Message                                  |
+-------+------+------------------------------------------+
| Note  | 1249 | Select 2 was reduced during optimization |
+-------+------+------------------------------------------+

Нет нет нет! Не идите этим путем! Это самый очевидный, но также самый неверный способ! Почему? А вот почему: SELECT в условии WHERE будет выполняться для каждой строки! А это число может составлять от 0 до 4091 строки, в зависимости от того насколько вы будете удачливы.

Нам нужен такой способ выборки, при котором мы будем уверены что случайный номер генерируется только однажды:

SELECT name
FROM random
JOIN
(
  SELECT CEIL(RAND() * (SELECT MAX(id) FROM random)) AS id
) AS r2
USING (id);
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     |            | system |    1 |                              |
|  1 | PRIMARY     | random     | const  |    1 |                              |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

Внутренний SELECT генерирует константу в TEMPORARY таблицу и JOIN выбирает одну строку. Великолепно! Нет сортировок, нет вмешательства приложения. Все части запроса оптимизированы.

#3. Добавляем “дыры” в primary key

Для того чтобы сделать наше предыдущее решение более универсальным, нам нужно учесть возможность “дыр” в ID (как если бы вы удалили некоторые строки).

SELECT name
FROM random AS r1 JOIN
(
 SELECT (RAND() * (SELECT MAX(id) FROM random)) AS id
)
AS r2
WHERE r1.id >= r2.id
ORDER BY r1.id ASC
LIMIT 1;
+----+-------------+------------+--------+------+------------------------------+
| id | select_type | table      | type   | rows | Extra                        |
+----+-------------+------------+--------+------+------------------------------+
|  1 | PRIMARY     |            | system |    1 |                              |
|  1 | PRIMARY     | r1         | range  |  689 | Using where                  |
|  2 | DERIVED     | NULL       | NULL   | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL | Select tables optimized away |
+----+-------------+------------+--------+------+------------------------------+

Теперь JOIN добавляет все ID который больше или равны нашему случайному значению и мы выбираем ближайшего соседа, если равенство не возможно. НО как только одна строка найдена мы останавливаемся (LIMIT 1). И мы читаем строки в соответствии с индексом (ORDER BY id ASC). Так как мы используем знак “>=” вместо строгого равенства “=” мы можем избавиться от CEIL и получить тот же резудьтат при немного меньших затратах.

#4. Равномерное распределение

Поскольку распределение ID не равномерно, наша выборка на самом деле стала не совсем случайной (прим. пер.: насколько я понимаю, чем больше “больших” дыр в ID тем менее равномерно распределение и тем “менее случайной” будет выборка).

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      107 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |       50 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      132 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      230 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      481 |
+----+----------------------------------+----------+

Функция RAND генерирует ID от 9 до 15, которые попадают в “дыру” перед 16 и как следствие, 16 выбирается намного чаще чем остальные.

Для этой проблемы не существует нормального решения, но если ваши данные более-менее постоянны, вы можете добавить таблицу для маппинга номера строки с ее ID:

> create table holes_map (
>   row_id int not NULL primary key,
>   random_id int not null
> );
> SET @id = 0;
> INSERT INTO holes_map SELECT @id := @id + 1, id FROM holes;
> select * from holes_map;
+--------+-----------+
| row_id | random_id |
+--------+-----------+
|      1 |         1 |
|      2 |         2 |
|      3 |         4 |
|      4 |         8 |
|      5 |        16 |
+--------+-----------+

Идентификатор row_id теперь не содержит дыр и мы опять можем воспользоваться нашим запросом:

SELECT name
FROM holes
JOIN (
  SELECT r1.random_id
  FROM holes_map AS r1
  JOIN (
    SELECT (RAND() * (SELECT MAX(row_id) FROM holes_map)
  ) AS row_id
) AS r2
WHERE r1.row_id >= r2.row_id
ORDER BY r1.row_id ASC
LIMIT 1) as rows ON (id = random_id);

После 1000 попыток опять имеем равномерное распределение:

> select * from holes;
+----+----------------------------------+----------+
| id | name                             | accesses |
+----+----------------------------------+----------+
|  1 | d12b2551c6cb7d7a64e40221569a8571 |      222 |
|  2 | f82ad6f29c9a680d7873d1bef822e3e9 |      187 |
|  4 | 9da1ed7dbbdcc6ec90d6cb139521f14a |      195 |
|  8 | 677a196206d93cdf18c3744905b94f73 |      207 |
| 16 | b7556d8ed40587a33dc5c449ae0345aa |      189 |
+----+----------------------------------+----------+

#5. Обслуживание таблицы Holes при помощи триггеров

Давайте подготовим таблицы как описано ниже:

DROP TABLE IF EXISTS r2;
CREATE TABLE r2 (
  id SERIAL,
  name VARCHAR(32) NOT NULL UNIQUE
);

DROP TABLE IF EXISTS r2_equi_dist;
CREATE TABLE r2_equi_dist (
  id SERIAL,
  r2_id bigint unsigned NOT NULL UNIQUE
);

Когда мы что-то меняем в r2, мы хотим чтобы r2_equi_dist также изменялась.

DELIMITER $$
DROP TRIGGER IF EXISTS tai_r2$$
CREATE TRIGGER tai_r2
AFTER INSERT ON r2 FOR EACH ROW
BEGIN
DECLARE m BIGINT UNSIGNED DEFAULT 1;

SELECT MAX(id) + 1 FROM r2_equi_dist INTO m;
SELECT IFNULL(m, 1) INTO m;
INSERT INTO r2_equi_dist (id, r2_id) VALUES (m, NEW.id);
END$$
DELIMITER ;

DELETE FROM r2;

INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );
INSERT INTO r2 VALUES ( NULL, MD5(RAND()) );

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  2 | a09a3959d68187ce48f4fe7e388926a9 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     2 |
|  3 |     3 |
|  4 |     4 |
+----+-------+

INSERT весьма прост. При DELETE же мы хотим поддерживать equi-dist-id в состоянии “без дыр”:

DELIMITER $$
DROP TRIGGER IF EXISTS tad_r2$$
CREATE TRIGGER tad_r2
AFTER DELETE ON r2 FOR EACH ROW
BEGIN
DELETE FROM r2_equi_dist WHERE r2_id = OLD.id;
UPDATE r2_equi_dist SET id = id - 1 WHERE r2_id > OLD.id;
END$$
DELIMITER ;

DELETE FROM r2 WHERE id = 2;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
|  4 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |     4 |
+----+-------+

UPDATE также прост. Мы должны обслужить лишь Foreign Key constraint:

DELIMITER $$
DROP TRIGGER IF EXISTS tau_r2$$
CREATE TRIGGER tau_r2
AFTER UPDATE ON r2 FOR EACH ROW
BEGIN
UPDATE r2_equi_dist SET r2_id = NEW.id WHERE r2_id = OLD.id;
END$$
DELIMITER ;

UPDATE r2 SET id = 25 WHERE id = 4;

SELECT * FROM r2;
+----+----------------------------------+
| id | name                             |
+----+----------------------------------+
|  1 | 8b4cf277a3343cdefbe19aa4dabc40e1 |
|  3 | 4e1897cd6d326f8079108292376fa7d5 |
| 25 | 29a5e3ed838db497aa330878920ec01b |
+----+----------------------------------+
SELECT * FROM r2_equi_dist;
+----+-------+
| id | r2_id |
+----+-------+
|  1 |     1 |
|  2 |     3 |
|  3 |    25 |
+----+-------+

#6. Несколько случайных строк за один раз

Если вы хотите получить более одной случайной строки за раз вы можете:

1. Выполнить запрос несколько раз
2. Написать хранимую процедуру, которая выполняет запрос и хранит результат во временной таблице
3. Выполнить UNION наконец

Хранимая процедура:

Хранимая процедура позволяет вам использовать структуры, известные в любом популярном языке программирования:

1. Циклы
2. Управляющие конструкции
3. Процедуры
4. …

Для нашей задачи нам нужен только цикл LOOP:

DELIMITER $$
DROP PROCEDURE IF EXISTS get_rands$$
CREATE PROCEDURE get_rands(IN cnt INT)
BEGIN
DROP TEMPORARY TABLE IF EXISTS rands;
CREATE TEMPORARY TABLE rands ( rand_id INT );

loop_me: LOOP
IF cnt < 1
  THEN LEAVE loop_me;
END IF;
INSERT INTO rands
  SELECT r1.id
  FROM random AS r1
  JOIN (
    SELECT (RAND() * (SELECT MAX(id) FROM random)) AS id
  ) AS r2
  WHERE r1.id >= r2.id
ORDER BY r1.id ASC
LIMIT 1;

SET cnt = cnt - 1;
END LOOP loop_me;
END$$
DELIMITER ;

CALL get_rands(4);
SELECT * FROM rands;
+---------+
| rand_id |
+---------+
|  133716 |
|  702643 |
|  112066 |
|  452400 |
+---------+

Оставляю в качестве заданий читателю следующие задачки:

1. Динамически составлять запрос, генерируя название временной таблицы (спасибо 2 Evgeny Babin)
2. Используя UNIQUE index отлавливать нарушения UNIQUE key для удаления возможных дублей.

#7. Быстродействие

Чтоже стало с быстродействием? У нас есть 3 различные запроса, решающие нашу проблему:

1. Q1. ORDER BY RAND()
2. Q2. RAND() * MAX(ID)
3. Q3. RAND() * MAX(ID) + ORDER BY ID

Q1 можно оценить как N * log2(N), Q2 и Q3 что-то около константы.

Чтобы получить реальные значения мы провели несколько тестов с числом строк от 100 до миллиона и выполнили каждый запрос 1000 раз.

    100        1.000      10.000     100.000    1.000.000
Q1  0:00.718s  0:02.092s  0:18.684s  2:59.081s  58:20.000s
Q2  0:00.519s  0:00.607s  0:00.614s  0:00.628s   0:00.637s
Q3  0:00.570s  0:00.607s  0:00.614s  0:00.628s   0:00.637s

Как вы можете видеть, простой ORDER BY RAND() оптимизирован для выполнения при количестве строк не более 100.

По мотивам http://jan.kneschke.de/projects/mysql/order-by-rand/

Coding with fun!

P.S. Сам я на практике использовал пока лишь 3е решение ))

Рассказывается о том как XLIFF переводы (текст в шаблонах) хранить в MySQL. По образу и подобию можно воспользоваться gettext или SQLite. В принципе можно и свой адаптер написать.

Спасибо, Женя )

Начальные условия.

Имеется symfony 1.4 проект с установленным sfDoctrineGuardPlugin.

Цели.

Требуется реализовать для пользователя список ежедневных задач (памятка).

Решение.

Схема.

Создадим в БД следующие таблицы:

# таблица ежедневных задач
CREATE TABLE IF NOT EXISTS `daily_task` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `daily_task_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1;

# таблица связей many-to-many задач и sfGuardUser
CREATE TABLE IF NOT EXISTS `user_has_daily_task` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `daily_task_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id_idx` (`user_id`),
  KEY `daily_task_id_idx` (`daily_task_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1;

# внешние ключи для связок
ALTER TABLE `user_has_daily_task`
  ADD CONSTRAINT `daily_task_id_idx` FOREIGN KEY (`daily_task_id`) REFERENCES `daily_task` (`id`),
  ADD CONSTRAINT `user_id_idx` FOREIGN KEY (`user_id`) REFERENCES `sf_guard_user` (`id`);

Этой структуре соответствует следующая схема Doctrine:

# схема для таблицы daily_task
DailyTask:
  connection: doctrine
  tableName: daily_task
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: true
    daily_task_name:
      type: string(255)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
  relations:
    UserHasDailyTask:
      local: id
      foreign: daily_task_id
      type: many
      onDelete: NO ACTION
      onUpdate: NO ACTION
# схема для таблицы user_has_daily_task
UserHasDailyTask:
  connection: doctrine
  tableName: user_has_daily_task
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: true
    user_id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    daily_task_id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
  relations:
    sfGuardUser:
      local: user_id
      foreign: id
      type: one
      onDelete: NO ACTION
      onUpdate: NO ACTION
    DailyTask:
      local: daily_task_id
      foreign: id
      type: one
      onDelete: NO ACTION
      onUpdate: NO ACTION

Выполняем пересоздание классов Doctrine (модели, формы, фильтры) и очищаем кэш:

$ ./symfony doctrine:build --all-classes
$ ./symfony cache:clear

Подготовительную часть на этом можно считать завершенной.

Админ-генератор sfGuardUser

Теперь на уровне БД у нас есть привязка ежедневных задач к пользователю sfGuardUser. Для редактирования пользователя sfGuard предусматривает одноименный модуль sfGuardUser с админ-генератором. По-умолчанию этот модуль позволяет редактировать имя, пароль пользователя, а также группы и список прав доступа. Вот они то нас и интересуют. Почему? Потому что эти параметры также представляют из себя связки many-to-many, а значит, если мы хотим добавить ежедневные задачи в редактирование пользователя, то сделать это логично по образу и подобию.

Модель sfGuardUser

Для того чтобы sfGuardUser корректно понимал нашу новую связь, необходимо модифицировать сгенерированный класс его модели следующим образом:

# lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php
class sfGuardUser extends PluginsfGuardUser
{
  public function setUp()
  {
    parent::setUp();
    $this->hasMany('DailyTask', array(
      'refClass'  => 'UserHasDailyTask',
      'local'     => 'user_id',
      'foreign'   => 'daily_task_id'
    ));
  }
}

Отлично, теперь модель пользователя знает о новой связке ) Теперь можно заняться формой

Форма sfGuardUserForm

Теперь мы можем модифицировать форму sfGuardUserForm. Для начала добавим виджет для нашего нового поля (виджет назовем daily_tasks_list):

# lib/form/doctrine/sfDoctrineGuardPlugin/sfGuardUserForm.class.php
class sfGuardUserForm extends BasesfGuardUserAdminForm
{
  public function configure()
  {
    $this->widgetSchema['daily_tasks_list'] = new sfWidgetFormDoctrineChoice(array(
      'multiple'  => true,
      'model'     => 'DailyTask'
    ));

    $this->validatorSchema['daily_tasks_list'] = new sfValidatorDoctrineChoice(array(
      'multiple'  => true,
      'model'     => 'DailyTask',
      'required'  => false
    ));
}

Тут желательно еще раз пересобрать все классы и очистить кэш.

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

Сохранение новой связки

Небольшое лирическое отступление, написанное по здравому размышлению. Если у вас виджет называется точно также как таблица + _list (в нашем случае это будет daily_task_list), то, скорее всего вы уже готовы использовать форму по полной. Я же назвал виджет не так как таблицу (в статье еще опущен префикс таблицы) и поимел последующий геморрой, который все-таки считаю нужным описать полностью.

Вот тут нам пригодится аналогия с группами и правами доступа. Если покопошиться в исходниках плагина, выяснится, что для сохранения связей, реализовано два дополнительных метода – savegroupsList и savepermissionsList. Т.о. мы реализуем наш метод savedailytasksList и переопределяем метод doSave():

# lib/form/doctrine/sfDoctrineGuardPlugin/sfGuardUserForm.class.php
class sfGuardUserForm extends BasesfGuardUserAdminForm
{
  //...
  /**
   * Сохранение списка ежедневных задач
   */
  public function savedailytasksList($con = null)
  {
    if (!$this->isValid())
    {
      throw $this->getErrorSchema();
    }
    if (!isset($this->widgetSchema['daily_tasks_list']))
    {
      // somebody has unset this widget
      return;
    }
    if (null === $con)
    {
      $con = $this->getConnection();
    }
    $existing = $this->object->DailyTask->getPrimaryKeys();
    $values = $this->getValue('daily_tasks_list');
    if (!is_array($values))
    {
      $values = array();
    }
    $unlink = array_diff($existing, $values);
    if (count($unlink))
    {
      $this->object->unlink('DailyTask', array_values($unlink));
    }
    $link = array_diff($values, $existing);
    if (count($link))
    {
      $this->object->link('DailyTask', array_values($link), true);
    }
  }

  /**
   * Сохранение формы
   */
  protected function doSave($con = null)
  {
    $this->savedailytasksList($con);
    parent::doSave($con);
  }
}

Ура! Теперь мы можем сохранять наши задачи! )) Остался один маленький заключительный штришок – сохранить то мы сохраняем, но при повторном редактировании пользователя сохраненные связи не отображаются. Для этого переопределим метод определения значения по-умолчанию для виджета:

# lib/form/doctrine/sfDoctrineGuardPlugin/sfGuardUserForm.class.php
class sfGuardUserForm extends BasesfGuardUserAdminForm
{
  //...

  /**
   * Значение по-умолчанию для виджета ежедневных задач
   */
  public function updateDefaultsFromObject()
  {
    parent::updateDefaultsFromObject();
    if (isset($this->widgetSchema['daily_tasks_list']))
    {
      $this->setDefault('daily_tasks_list', $this->object->DailyTask->getPrimaryKeys());
    }
  }
}

Ну вот, кажется и все! Пользуйтесь на здоровье )) И ставьте “плюсики”, если понравилось! ))

// config/ProjectConfiguration.class.php:
public function configureDoctrine(Doctrine_Manager $manager)
{
  $manager->setCharset( 'utf8' );
  $manager->setCollate( 'utf8_unicode_ci' );
}

Спасибо Андрэю Дзягелю из русскоговорящего symfony-коммьюнити )

Собственно казалось бы, используем конструкцию $criteria->addAsColumn(…) и все. Но не тут то было, при использовании этого запроса теряются все колонки, выбираемые по-умолчанию Propel’ом.

Итак, вот, пример запроса который нам нужно выполнить:

SELECT
    `table`.`id`,
    `table`.`field1`,
    `table`.`field2`,
    CASE
    WHEN
        `table`.`photo_count` > 0
    THEN 1
    WHEN
        `table`.`photo_count` = 0
    THEN 0
    END as has_photo
FROM
    `table`
WHERE
    `table`.`status_id` = 2
AND
    `table`.`type_id` = 1
...
ORDER BY
    has_photo DESC,
    `table`.`created_at` DESC

Ключевые особенности – дополнительное “поле” photo_count принимает значение 0 или 1 и по нему осуществляется сортировка. При этом на выходе мы хотим получить Propel-объекты.

На самом деле решение очень простое:

PropertyPeer::addSelectColumns( $criteria );
$criteria->addAsColumn(
    "has_photo" ,
    "CASE WHEN " . TablePeer::PHOTO_COUNT . " > 0 THEN 1 " .
    "WHEN " . TablePeer::PHOTO_COUNT . " = 0 THEN 0 END"
);
$criteria->addDescendingOrderByColumn( "has_photo" );

Ключевой особенностью этого решения является первая строка. Просто, не так ли? Тем не менее чтобы найти решение проблемы потребовался не один час, куча нервов. Собственно ответ был найден в trac’е propel – http://propel.phpdb.org/trac/ticket/643

с уважением, отдел по борьбе с propel )))

Числа

Создавать большие наборы числовых данных совсем не сложно.

Возможно вы захотите написать цикл на вашем любимом языке программирования, или даже цикл в хранимой процедуре на SQL, но это займет намного больше времени, чем предлагаемый ниже подход, который позволит заполнить таблицу за несколько секунд:

drop table if exists numbers;
create table numbers ( id int not null primary key);

delimiter $$

drop procedure if exists fill_numbers $$
create procedure fill_numbers()
deterministic
begin
  declare counter int default 1;
  insert into numbers values (1);
  while counter < 1000000
  do
      insert into numbers (id)
          select id + counter
          from numbers;
      select count(*) into counter from numbers;
      select counter;
  end while;
end $$
delimiter ;

call fill_numbers();

Данный способ намного более быстрый, нежели прямая вставка 1’000’000 строк. Мы вставляем в таблицу всего одну строку, и потом дублируем таблицу 20 раз, пока не получим 1’048’576 строк (2²⁰). Эта операция занимает менее 8 секунд на ноутбуке автора, который намного менее мощный, нежели средний сервер (на момент написания статьи – 2006г. // hudson). Даже если вы не хотите использовать хранимую процедуру, вы можете вручную вставить 1 строку и выполнить 20 раз следующий запрос:

insert into
    numbers (id)
select
    id + (select count(*) from numbers)
from
    numbers; 

select count(*) from numbers;

Эта процедура не займет у вас больше 30 секунд.

Слова

Если вам нужно работать с большим объемом уникальных строковых данных, вы опять таки, можете написать программу на любом языке, однако это будет совсем не быстро (процесс вставки достаточно медленный). Наиболее быстрый способ – загрузить готовый список слов из файла. Все Unix системы содержат списки слов – от нескольких тысяч, до полумиллиона. Если вдруг у вас такого не оказалось, вы можете скачать его из множества доступных источников или собрать самостоятельно (для начала можете посмотреть здесь: ftp://ftp.cerias.purdue.edu/pub/dict/ или здесь ftp://ftp.ox.ac.uk/pub/wordlists/).

И, наконец, покажем как имея на руках файл с примерно полумиллионом слов /usr/share/dict/words, вы сможете наполнить тестовую таблицу:

drop table if exists words;
create table words (
  id int not null auto_increment primary key,
  t varchar(50) not null
);

load data local infile '/usr/share/dict/words'
  into table words (t);

Query OK, 518584 rows affected (4.94 sec)
Records: 518584  Deleted: 0  Skipped: 0  Warnings: 0

select count(*) from words;
+----------+
| count(*) |
+----------+
|   518584 |
+----------+
1 row in set (0.04 sec)

Быстро, не правда ли? Но постойте-ка, у нас пока что есть только пол миллиона записей (ну… чуть больше). Так как нам нужны уникальные слова, мы можем попросить базу данных, изменить порядок букв в уже существующих (reverse()):

insert into words (t) select reverse(t) from words;
Query OK, 518584 rows affected (3.98 sec)
Records: 518584  Duplicates: 0  Warnings: 0

select count(*) from words;
+----------+
| count(*) |
+----------+
|  1037168 |
+----------+

Вот так вот! Но мы все еще можем сомневаться, уникальны ли эти слова, так как изменение порядка букв одного слова может превратить его в другое (например mood <–> doom). Т.о. чтобы считать нашу задачу завершенной, нужно добавить UNIQUE индекс с опцией IGNORE, что позволит исключить дубликаты:

alter ignore table words add unique key (t);
Query OK, 1037168 rows affected (46.69 sec)
Records: 1037168  Duplicates: 5791  Warnings: 0

select count(*) from words;
+----------+
| count(*) |
+----------+
|  1031377 |
+----------+

Вот так – миллион слов, не напрягаясь )

Даты

Наконец, давайте посмотрим, как можно быстро и просто создавать большие наборы дат. Фактически, миллион разных дат вам вряд ли понадобится, т.к. миллион дней это более 2700 лет. Т.о. только даты будут покрывать диапазон от 1000 до 10000 дней, вряд ли больше. Если же вам нужен миллион записей, то впору поговорить не о DATE а о DATETIME с интервалами в часы, минуты или даже секунды. Никто не запрещает вам использовать эту технику для создания сотни уникальных DATE, но при этом иметь в таблице что-то около миллиона записей. Итак, если мы хотим создать записи с минутным интервалом то нужно выполнить следующий код:

drop table if exists dates;
create table dates (
  id int(11) not null auto_increment primary key,
  dt datetime not NULL
) engine=myisam;

delimiter $$

drop procedure if exists make_dates $$
CREATE PROCEDURE make_dates( max_recs int)
begin
  declare start_dt datetime;
  declare numrecs int default 1;
  set start_dt = date_format( now() - interval max_recs minute, '%Y-%m-%d %H:%i:00');

  insert into dates (dt) values (start_dt );

  while numrecs < max_recs
  do
      insert into dates (dt)
          select dt + interval ( numrecs ) minute
          from dates;
      select count(*) into numrecs from dates;
      select numrecs;
  end while;
end $$

delimiter ;

Выглядит знакомо, не правда ли? ) Неудивительно, ведь ту же технику мы использовали для заполнения таблицы с числами. Хотя в отличие от чисел, здесь мы использовали число записей в таблице для вычисления интервала в минутах между существующими записями и теми записями, которые будут добавлены в этой итерации. Но мы также дублируем таблицу 20 раз, чтобы получить 1’000’000 записей.

call make_dates( 1000000 );
+---------+
| numrecs |
+---------+
|       2 |
+---------+
1 row in set (0.02 sec)

+---------+
| numrecs |
+---------+
|       4 |
+---------+
1 row in set (0.02 sec)

# ... 16 more counts

+---------+
| numrecs |
+---------+
|  524288 |
+---------+
1 row in set (5.99 sec)

+---------+
| numrecs |
+---------+
| 1048576 |
+---------+
1 row in set (10.18 sec)

select count(*), min(dt), max(dt) from dates;
+----------+---------------------+---------------------+
| count(*) | min(dt)             | max(dt)             |
+----------+---------------------+---------------------+
|  1048576 | 2004-07-07 13:57:00 | 2006-07-05 18:12:00 |
+----------+---------------------+---------------------+

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

Заключение

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

p.s. как и обещал, это перевод статьи http://datacharmer.blogspot.com/2006/06/filling-test-tables-quickly.html