Ситуация: есть несколько физических почтовых серверов (PowerMTA), отсылающих более четырёх миллионов сообщений в сутки. Есть виртуальный сервер базы данных (причём не очень мощный), на котором крутится MySQL с InnoDB; в базу данных пишутся логи доставки/не доставки сообщений и ведётся статистика по IP-адресам, VMTA и доменам. Попутно выполняется классификация и анализ hard и soft bounces. База за день увеличивается примерно на 5 гигабайт. Часть логов недельной давности удаляется.

Так как с базой (на запись) работает несколько клиентов, структура таблиц/индексы выбраны таким образом, чтобы обеспечить максимальную скорость добавления записей и минимум блокировок.

Проблема возникла с ведением статистики.

Есть таблица такой структуры:

В таблицу заносятся данные о доставке сообщений — выполняется это триггерами post insert: при доставке сообщения в таблицу заносится запись (NULL, DATE_FORMAT(NOW(), "%Y%m%d"), domain, vmta, ip, 1, 0, 0, 0, 0), при получении hard bounce — (NULL, DATE_FORMAT(NOW(), "%Y%m%d"), domain, vmta, ip, 0, 1, 0, 0, 0) — всё это выполняется довольно быстро, жалоб нет.

Проблемы начинаются при обработке данного лога. Что нужно сделать: подсчитать SUM(deliveries), SUM(bounces), SUM(transients), SUM(pmta_bounces) для каждой четвёрки (ymd, domain, vmta, ip). Данная операция выполняется каждые десять минут. Обработанные данные из таблицы log нужно удалить.

В терминах SQL это выглядит примерно так:

Проблема наступает при выполнении оператора DELETE: SHOW PROCESSLIST показывает состояние Updating минуты полторы, после чего в лог пишется печально известное сообщение Lock wait timeout exceeded; try restarting transaction и транзакция откатывается. При этом количество записей в таблице log всего лишь порядка 80,000.

В принципе, проблема с DELETE давно известна: в InnoDB удаление строк весьма тормозное. По всей видимости, это усугубляется тем, что в таблицу постоянно идёт запись новых данных. Руководство пользователя объясняет суть проблемы.

А решение таково: заводим дополнительную колонку в таблице (processed) и создаём по ней индекс. DELETE FROM log WHERE id <= max_id заменяем на UPDATE log SET processed = 1 WHERE id <= max_id, что выполняется гораздо быстрее. Затем заводим еще одну транзакцию, в которой удаляем строки с processed = 1.

Но в один заход все строки удалить не получится, поэтому придётся идти на хитрость:

Смысл в том, что удаление производится небольшими кусками (что будет относительно быстро); каждое удаление выполняется в своей транзакции (в случае блокировки транзакции в хвосте таблицы большая часть записей будет удалена, что не так плохо).

Вполне возможно, что можно обойтись без дополнительной колонки и использовать REPEAT … END REPEAT с DELETE FROM log WHERE id <= max_id, но текущий вариант работает, кушать не просит, блокировок не создаёт. А наше основное правило — si fractum non sit, noli id reficere.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

В статье «Подсчёт трафика в nginx» я приводил один из возможных вариантов живого подсчёта трафика в nginx.

У прошлого решения есть недостатки:

• используется три лишних процесса;
• используется много файловых дескрипторов (зависит от количества виртуальных хостов).

Я на днях нашёл еще один вариант.

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

Основное отличие — не используются поля, которые легко вычислить (`sum` = `in` + `out`, `ym` = EXTRACT(YEAR_MONTH FROM `dt`)) и отсутствуют индексы (ибо при высокой посещаемости сжимать таблицу на живую — это самоубийство чистой воды).

Переходим к магии.
Создаём лог:

А далее, если Вы хорошо знакомы с программированием под Linux/Unix, наверное, догадались: во все виртуальные хосты прописываем

Формат trafctr определён следующим образом (извращение):

Фактически, в pipe будет писаться такой запрос:

SUBSTR() убирает хвост в виде часового пояса, STR_TO_DATE() используется для создания строки с временем, которую поймёт UNIX_TIMESTAMP(), а CONCAT()… Что же, CONCAT() нужен, чтобы nginx не ругался на строки вида %d/%b/%Y:%H:%i:%s. Не любит nginx знак процента.

Как данные попадают в базу? Всё просто:

Следующий этап (часть 3): написание демона, заменяющего mysql (как процесс). Демон будет сжимать данные на лету и передавать их MySQL-серверу. Благодаря этому мы снизим нагрузку на MySQL (запросы будут передаваться в виде extended insert, а сами данные уже будут просуммированы).

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Постановка задачи: есть Linux-сервер, на котором живёт сотня-другая виртуальных хостов. Сервер работает под управлением nginx. Нужно реализовать подсчет трафика с отображением «живой» статистики.

Вариант решения:

Таблица для хранения данных:

Фрагменты конфигурационного файла nginx:

Каждый виртуальный хост должен содержать подобную строку:

В логе будут записи вида

А теперь собственно чёрная магия с использованием awk:

Удалось обойтись тремя лишними процессами: mysql, awk и tail (вместо пяти: mysql, awk, tail, egrep и sed).

Подсчёт трафика в nginx: часть 2.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Например, для WordPress (при условии, что пара (user_id, meta_key) является уникальным ключом):

Должно работать.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Хотя я люблю WordPress, но то, что я увидел сегодня в коде, меня сильно потрясло.

Речь пойдёт о виджетах, а именно, о календаре и архиве. Я вкратце опишу реализацию каждого из них, а затем расскажу, почему так делать нельзя.

Начнём с виджета архивов.

В самом простом случае (если не установлено никаких сторонних плагинов, которые могут повлиять на запросы виджета), получение данных для формирования архива производится таким вот запросом (в зависимости от опций виджета запрос может отличаться):

В случае, если в базе данных хранится несколько тысяч статей и все они опубликованы, фильтрация по полям post_type и post_status мало что даст (если только записи не содержат много вложений), так как всё равно будут выбраны почти все записи. Затем выбранные записи будут группироваться по выражению, и конечный результат будет отсортирован. Проблема здесь состоит в том, что MySQL может использовать только один индекс, и он его использует — для нахождения опубликованных статей. А вот для группировки и сортировки индексы MySQL использовать не сможет: в случае с группировкой из-за того, что используется группировка по выражению, а в случае с сортировкой — потому что группировка и сортировка осуществляются по разным полям.

Запустив EXPLAIN, мы увидим, как всё плохо:

Во-первых, длина ключа не радует: 124 байта — это перебор. Сравнение длинных строк неэффективно, и чем больше похожих или одинаковых строк, тем хуже производительность.

Во-вторых, использование временной таблицы. Создание временной таблицы (пусть даже в памяти) — это лишнее время. Если таблица становится слишком большой, она сбрасывается на диск и преобразовывается в другой формат. Еще больше потерянного времени.

В-третьих, использование файловой сортировки. MySQL не смог использовать индекс для сортировки; как следствие, ему придётся сделать еще один проход с просмотром всех записей. Опять теряется драгоценное время.

Можно, конечно, поспорить, что современное железо очень быстрое, а память дешёвая. Да, всё так. Но есть одно но: такое решение очень плохо масштабируется. Как следствие, изобретаются различные костыли в виде кэширования. Но не проще ли было нормально спроектировать базу данных?

Как ни крути, запрос переписать невозможно: с ростом количества опубликованных статей производительность будет падать. Что-то мне подсказывает, что нелинейно. А с увеличением количества посетителей производительность будет падать еще сильнее. В результате может упасть MySQL. Или его убьёт знаменитый OOM Killer.

Что нужно было сделать: ввести избыточность в базу данных. С точки зрения третьей нормальной формы это звучит кощунственно. Но избыточность позволяет повысить производительность.

Я внёс изменения в таблицу wp_posts:

Затем переписал запрос:

DISTINCT в запросе явно лишний, потому что группировка по году и месяцу гарантирует, что каждая пара (год, месяц) в результирующем наборе будет уникальной. Сортировка по полной дате также бессмысленна, ибо точность до дня в запросе не нужна.

В результате получаем:

Никаких временных таблиц, никакой файловой сортировки. Ключ по-прежнему длинный, но это уже издержки производства. Лично я бы поменял VARCHAR на ENUM.

Теперь переходим к виджету календарь.

В нём четыре запроса, но каких!

1. Поиск самой недавней записи прошлых месяцев:
   SELECT DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
   FROM wp_posts
   WHERE post_date < '2008-11-01'
   AND post_type = 'post' AND post_status = 'publish'
   ORDER BY post_date DESC
   LIMIT 1

   Ну зачем нужен DISTINCT?!! Выбирается одна запись, в результирующем наборе она уникальна в любом случае.

   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                                     |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL | 3238 | Using where; Using index; Using temporary |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+

   Уберём DISTINCT и получим более красивый результат:

   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                    |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL | 3238 | Using where; Using index |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+

   Как видим, необходимость во временной таблице исчезла.

2. Поиск записи в последующих месяцах:
   SELECT DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
   FROM wp_posts
   WHERE post_date > '2008-11-01'
   AND MONTH( post_date ) != MONTH( '2008-11-01' )
   AND post_type = 'post' AND post_status = 'publish'
   ORDER BY post_date ASC
   LIMIT 1

   У нас это называют "начемоданечерезкитайскими методами". Про DISTINCT я уже говорил, в нём смысла нет. А с датой перемудрили: ищем статьи, написанные после первого числа этого месяца, но не в этом месяце. Не проще ли написать, что ищем статьи, написанные с первого числа следующего месяца?

   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                                     |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL |  356 | Using where; Using index; Using temporary |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+

   Исправим запрос:

   SELECT MONTH(post_date) AS month, YEAR(post_date) AS year
   FROM wp_posts
   WHERE post_date > '2008-11-31 23:59:59'
   AND post_type = 'post' AND post_status = 'publish'
   ORDER BY post_date ASC
   LIMIT 1
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                    |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL |    1 | Using where; Using index |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+--------------------------+
3. Поиск дней в текущем месяце, в которые была написана хотя бы одна статья:
   SELECT DISTINCT DAYOFMONTH(post_date)
   FROM wp_posts WHERE MONTH(post_date) = '11'
   AND YEAR(post_date) = '2008'
   AND post_type = 'post' AND post_status = 'publish'
   AND post_date < '2008-11-24 18:30:04'

   Очевидно, что MySQL сможет использовать только стратегию range. В случае, если рассматриваемый месяц является последним в базе данных, MySQL придётся просмотреть все записи, которые вернёт WHERE. Ибо не умеет MySQL использовать индексы с выражениями.

   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                                     |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL | 3594 | Using where; Using index; Using temporary |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+

   MySQL придётся просмотреть 3594 записи. А если мы перепишем запрос:

   SELECT DISTINCT DAYOFMONTH(post_date)
   FROM wp_posts
   WHERE post_date >= '2008-11-01 00:00:00'
   AND post_type = 'post' AND post_status = 'publish'
   AND post_date < '2008-11-24 18:30:04'
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra                                     |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL |  267 | Using where; Using index; Using temporary |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------------------------------------+

   Получим более, чем 10-кратную экономию. Ain't it sweet?

4. Получение дней и соответствующих им статей:
   SELECT post_title, DAYOFMONTH(post_date) as dom
   FROM wp_posts
   WHERE YEAR(post_date) = '2008'
   AND MONTH(post_date) = '11'
   AND post_date < '2008-11-24 18:30:04'
   AND post_type = 'post'
   AND post_status = 'publish'

   Та же самая ошибка, что и в прошлый раз.

   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------+
   | id | select_type | table    | type  | possible_keys              | key              | key_len | ref  | rows | Extra       |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------+
   |  1 | SIMPLE      | wp_posts | range | type_status_date,post_type | type_status_date | 132     | NULL | 3594 | Using where |
   +----+-------------+----------+-------+----------------------------+------------------+---------+------+------+-------------+
   Запрос переписывается аналогично. Переписали всего два запроса и получили ощутимый прирост в производительности.

Теперь, собственно, патчи.

• Патч для WordPress 2.6.x:
  --- general-template.php.original       2008-06-11 20:25:55.000000000 +0300
  +++ general-template.php        2008-11-24 20:37:42.000000000 +0200
  @@ -414,7 +414,7 @@
          $join = apply_filters('getarchives_join', "", $r);
   
          if ( 'monthly' == $type ) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC $limit";
  +               $query = "SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC $limit";
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -435,7 +435,7 @@
                          }
                  }
          } elseif ('yearly' == $type) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date) ORDER BY post_date DESC $limit";
  +               $query = "SELECT YEAR(post_date) AS `year`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date) ORDER BY post_date DESC $limit";
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -456,7 +456,7 @@
                          }
                  }
          } elseif ( 'daily' == $type ) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, DAYOFMONTH(post_date) AS `dayofmonth`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date), DAYOFMONTH(post_date) ORDER BY post_date DESC $limit";
  +               $query = "SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, DAYOFMONTH(post_date) AS `dayofmonth`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date), DAYOFMONTH(post_date) ORDER BY post_date DESC $limit";
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -557,7 +557,7 @@
          ob_start();
          // Quick check. If we have no posts at all, abort!
          if ( !$posts ) {
  -               $gotsome = $wpdb->get_var("SELECT ID from $wpdb->posts WHERE post_type = 'post' AND post_status = 'publish' ORDER BY post_date DESC LIMIT 1");
  +               $gotsome = $wpdb->get_var("SELECT ID from $wpdb->posts WHERE post_type = 'post' AND post_status = 'publish' LIMIT 1");
                  if ( !$gotsome )
                          return;
          }
  @@ -591,16 +591,16 @@
          $unixmonth = mktime(0, 0 , 0, $thismonth, 1, $thisyear);
   
          // Get the next and previous month and year with at least one post
  -       $previous = $wpdb->get_row("SELECT DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
  +       $previous = $wpdb->get_row("SELECT MONTH(post_date) AS month, YEAR(post_date) AS year
                  FROM $wpdb->posts
                  WHERE post_date < '$thisyear-$thismonth-01'
                  AND post_type = 'post' AND post_status = 'publish'
                          ORDER BY post_date DESC
                          LIMIT 1");
  -       $next = $wpdb->get_row("SELECT  DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
  +       $last_day = date('t');
  +       $next = $wpdb->get_row("SELECT MONTH(post_date) AS month, YEAR(post_date) AS year
                  FROM $wpdb->posts
  -               WHERE post_date >       '$thisyear-$thismonth-01'
  -               AND MONTH( post_date ) != MONTH( '$thisyear-$thismonth-01' )
  +               WHERE post_date > '$thisyear-$thismonth-{$last_day} 23:59:59'
                  AND post_type = 'post' AND post_status = 'publish'
                          ORDER   BY post_date ASC
                          LIMIT 1");
  @@ -655,8 +655,7 @@
   
          // Get days with posts
          $dayswithposts = $wpdb->get_results("SELECT DISTINCT DAYOFMONTH(post_date)
  -               FROM $wpdb->posts WHERE MONTH(post_date) = '$thismonth'
  -               AND YEAR(post_date) = '$thisyear'
  +               FROM $wpdb->posts WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00'
                  AND post_type = 'post' AND post_status = 'publish'
                  AND post_date < '" . current_time('mysql') . '\'', ARRAY_N);
          if ( $dayswithposts ) {
  @@ -675,8 +674,7 @@
          $ak_titles_for_day = array();
          $ak_post_titles = $wpdb->get_results("SELECT post_title, DAYOFMONTH(post_date) as dom "
                  ."FROM $wpdb->posts "
  -               ."WHERE YEAR(post_date) = '$thisyear' "
  -               ."AND MONTH(post_date) = '$thismonth' "
  +               ."WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00' "
                  ."AND post_date < '".current_time('mysql')."' "
                  ."AND post_type = 'post' AND post_status = 'publish'"
          );
• Патч для WordPress 2.7b3:
  --- general-template.php.original       2008-11-13 09:45:11.000000000 +0200
  +++ general-template.php        2008-11-24 20:45:36.000000000 +0200
  @@ -750,7 +750,7 @@
          $output = '';
   
          if ( 'monthly' == $type ) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_da
  +               $query = "SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC $
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -771,7 +771,7 @@
                          }
                  }
          } elseif ('yearly' == $type) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date) ORDER BY post_date DESC $limit";
  +               $query = "SELECT YEAR(post_date) AS `year`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date) ORDER BY post_date DESC $limit";
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -792,7 +792,7 @@
                          }
                  }
          } elseif ( 'daily' == $type ) {
  -               $query = "SELECT DISTINCT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, DAYOFMONTH(post_date) AS `dayofmonth`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_d
  +               $query = "SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, DAYOFMONTH(post_date) AS `dayofmonth`, count(ID) as posts FROM $wpdb->posts $join $where GROUP BY YEAR(post_date), MON
                  $key = md5($query);
                  $cache = wp_cache_get( 'wp_get_archives' , 'general');
                  if ( !isset( $cache[ $key ] ) ) {
  @@ -913,7 +913,7 @@
          ob_start();
          // Quick check. If we have no posts at all, abort!
          if ( !$posts ) {
  -               $gotsome = $wpdb->get_var("SELECT ID from $wpdb->posts WHERE post_type = 'post' AND post_status = 'publish' ORDER BY post_date DESC LIMIT 1");
  +               $gotsome = $wpdb->get_var("SELECT ID from $wpdb->posts WHERE post_type = 'post' AND post_status = 'publish' LIMIT 1");
                  if ( !$gotsome )
                          return;
          }
  @@ -947,16 +947,16 @@
          $unixmonth = mktime(0, 0 , 0, $thismonth, 1, $thisyear);
   
          // Get the next and previous month and year with at least one post
  -       $previous = $wpdb->get_row("SELECT DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
  +       $previous = $wpdb->get_row("SELECT MONTH(post_date) AS month, YEAR(post_date) AS year
                  FROM $wpdb->posts
                  WHERE post_date < '$thisyear-$thismonth-01'
                  AND post_type = 'post' AND post_status = 'publish'
                          ORDER BY post_date DESC
                          LIMIT 1");
  -       $next = $wpdb->get_row("SELECT  DISTINCT MONTH(post_date) AS month, YEAR(post_date) AS year
  +       $last_day = date('t');
  +       $next = $wpdb->get_row("SELECT MONTH(post_date) AS month, YEAR(post_date) AS year
                  FROM $wpdb->posts
  -               WHERE post_date >       '$thisyear-$thismonth-01'
  -               AND MONTH( post_date ) != MONTH( '$thisyear-$thismonth-01' )
  +               WHERE post_date >       '$thisyear-$thismonth-{$last_day} 23:59:59'
                  AND post_type = 'post' AND post_status = 'publish'
                          ORDER   BY post_date ASC
                          LIMIT 1");
  @@ -1011,8 +1011,7 @@
   
          // Get days with posts
          $dayswithposts = $wpdb->get_results("SELECT DISTINCT DAYOFMONTH(post_date)
  -               FROM $wpdb->posts WHERE MONTH(post_date) = '$thismonth'
  -               AND YEAR(post_date) = '$thisyear'
  +               FROM $wpdb->posts WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00'
                  AND post_type = 'post' AND post_status = 'publish'
                  AND post_date < '" . current_time('mysql') . '\'', ARRAY_N);
          if ( $dayswithposts ) {
  @@ -1031,8 +1030,7 @@
          $ak_titles_for_day = array();
          $ak_post_titles = $wpdb->get_results("SELECT post_title, DAYOFMONTH(post_date) as dom "
                  ."FROM $wpdb->posts "
  -               ."WHERE YEAR(post_date) = '$thisyear' "
  -               ."AND MONTH(post_date) = '$thismonth' "
  +               ."WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00' "
                  ."AND post_date < '".current_time('mysql')."' "
                  ."AND post_type = 'post' AND post_status = 'publish'"
          );

Патч нужно применять к файлу wp-includes/general-template.php.

Патч для версии 2.7.1 (также решает проблему с #9197):

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Началось всё с того, что я забыл заплатить за Internet, и в благодарность за это мой провайдер меня безжалостно отрубил. Дело было вечером, делать было нечего, тем более, что я давно собирался написать статью про MySQL. И вот, когда я стал генерировать тестовую таблицу, начались чудеса…

Создал в MySQL таблицу:

PHP-скриптом запихнул в неё данные:

Сделал два INSERT:

В результате получил 4,000,000 строк в таблице.

Теперь самое интересное:

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

По ходу я нашел неизвестный баг в MyISAM?

$ mysql --version
mysql  Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (x86_64) using readline 5.2
$ uname -srvmo
Linux 2.6.24-21-server #1 SMP Mon Aug 25 17:28:54 UTC 2008 x86_64 GNU/Linux

Для очистки совести:

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

Сделал так:

Минут через пять я вспомнил, что CREATE TABLE ... SELECT не создаёт индексы. Я решил проверить догадку:

Вот они, чудеса! Точнее, баги. С индексом MySQL не находит нужные строки, без индекса же всё работает. Причем самое странное то, что не работает только k=5; другие значения срабатывают просто на "ура".

Что характерно: я грохнул 2 миллиона строк (эх!) и оптимизировал таблИцу, и всё заработало:

Затем добавил те самые два миллиона строк на место:

Что характерно: изменился порядок следования значений: теперь одинаковые значения k следуют друг за другом. Возможно, здесь "схитрил" оптимизатор — после DELETE перед INSERT я сделал OPTIMIZE.

Такие вот пироги… Так что заплачу за Интернет и пойду писать багрепорт.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Как известно, в целях безопасности сервер MySQL по умолчанию открыт для доступа только с локальной системы. Поэтому, когда на сервере не установлен phpMyAdmin, а консольной версией клиента пользоваться просто неудобно (ненаглядно), приходится открывать доступ для удаленного пользователя. Но такое решение не самое безопасное.

В таких случаях рекомендуется использовать методику, имеющую название port forwarding (перенаправление портов).

Например, чтобы обращение к localhost:7000 было эквивалентно обращению на remotehost:3306 с хоста remotehost от имени пользователя user, достаточно выполнить

Синтакс имеет вид

При доступе к порту localport локальной машины будет осуществлено соединение с remotehost на targethost:targetport.

Теперь инструктируем локальный MySQL-клиент соединяться с localhost:7000 и получаем доступ к MySQL на remotehost:3306.

Этот метод можно использовать не только для MySQL, но и для любых других серверов. Достоинства метода заключаются в том, что, во-первых, не надо открывать доступ к требуемому сервису из внешней сети, а во-вторых, соединение шифруется по протоколу SSH и, как следствие, является безопасным.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Я сейчас работаю над очень интересным проектом, который, как надеется заказчик, составит серьёзную конкуренцию Google Analytics. Но речь не об этом. Разбираясь с архитектурой системы, я обнаружил весьма интересную деталь: 8 гигабайт памяти сервера отдается под несколько таблиц типа HEAP. Так как HEAP-таблицы хранятся в исключительно в памяти, то операция вставки (INSERT) должна выполняться очень быстро, так как временные затраты, связанные с перемещением головок диска и физической записью, отсутствуют. Я решил найти подтверждение этой теории. Google is your friend, и я довольно быстро нашел статью MySQL Engine INSERT speed.

Меня несколько смутили результаты, приведённые автором:

• MyISAM (с DELAY_KEY_WRITE=ALL): 33 000 INSERT/сек
• InnoDB: 24 700 INSERT/сек
• MEMORY: 64 000 INSERT/сек

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

Первыми возникшими вопросами были:

1. Какой тип вставки использовался для MyISAM/InnoDB-таблиц — INSERT или INSERT DELAYED?
2. Каким образом вставлялись данные — построчно или блочно (extended insert)?
3. Значение AUTOCOMMIT при работе с таблицей InnoDB.

Об этом оставалось только гадать, поэтому я решил повторить этот эксперимент.

Методика эксперимента:
Создаются три таблицы:

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

Затем в цикле в таблицу вставлялись случайно сгенерированные данные (компьютер, на котором проводился эксперимент, был слабый, поэтому я ограничился тридцатью тысячами записями). После цикла выполнялся COMMIT. Скрипт выполнялся 10 раз, бралось среднее время.

Исходный текст скрипта:

У меня получились такие результаты (я привожу относительную — относительно таблиц типа HEAP — скорость):

Эксперимент показал, что разница по скорости между INSERT DELAYED для таблицы MyISAM и INSERT для таблицы HEAP очень незначительна. Таблицы InnoDB действительно оказались медленнее, но не сильно. Большую роль здесь могла сыграть «слабость» тестового компьютера и значение переменной innodb_flush_log_at_trx_commit. Вдобавок, MyISAM был сконфигурирован очень даже хорошо, в то время как InnoDB использовал практически значения по умолчанию (мне редко приходится пользоваться таблицами InnoDB, поэтому тонкой настройкой я не занимался). Тем не менее, результаты проведенного мной эксперимента совсем не согласуются с данными, приведёнными в исходной статье. Кто же из нас прав?

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Начну сразу с причин, по которым я пишу эту статью. Я периодически просматриваю лог запросов, по которому люди попадают сюда, и вот один из запросов — хранить php сессию в mysql.

Итак, как же хранить PHP-сессии в базе данных?

На самом деле, в этом нет ничего сложного: в PHP есть одна полезная функция — session_set_save_handler — которая и выполняет всю грязную работу:

session_set_save_handler() sets the user-level session storage functions which are used for storing and retrieving data associated with a session. This is most useful when a storage method other than those supplied by PHP sessions is preferred. i.e. Storing the session data in a local database.

Эта функция принимает шесть аргументов типа сallback:

• open — вызывается при открытии/создании сессии;
• close — вызывается при закрытии сессии (например, чтобы приложение могло закрыть файл);
• read — чтение сессии;
• write — запись сессии;
• destroy — уничтожение сессии (session_destroy());
• gc — «сборка мусора»

Все функции (кроме read) должны возвращать true, если все прошло успешно и false в противном случае.

Для хранения сессии у нас есть такая таблица:

Один маленький нюанс: если в MySQL делать таблицу сессий типа MEMORY (т.е. задать ей такой storage engine), то могут возникнуть проблемы с удалением записей при сборке мусора, ибо MEMORY storage engine не может использовать индексы для операций сравнения типа «больше»/«меньше».

Для абстракции от конкретного SQL-сервера, будем считать, что у нас имеется некий класс Persistent, обладающий способностями загружать/сохранять данные в базу данных.

Таким образом, реализация класса Session будет иметь следующий вид:

Пока все предельно просто. О переменной $m_new поговорим позже.

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

Пример использования:

Вкратце о $m_new. Дело в том, что ID сессии при ее открытии может не совпадать с ID при закрытии (иными словами, измениться в ходе выполнения скрипта). Один из способов — это использование функции session_regenerate_id(). Поэтому при сохранении сессии важно знать, является ID новым или нет (если ID новый, то для сохранения будет использоваться INSERT, если существующий — то UPDATE; по большому счету можно обойтись одним REPLACE, однако это не особо эффективное решение). Для этого при открытии сессии получаем текущий идентификатор сессии и сравниваем его с тем, который получаем при сохранении сессии (конечно, в этом простом случае можно было обойтись без лишней переменной, но в более сложных проектах она может понадобиться); в зависимости от их равенства/неравенства используем тот или иной метод сохранения данных.

Строка register_shutdown_function('session_write_close') гарантирует, что сессия будет сохранена (без нее в PHP4 у меня были случаи, когда сессия не сохранялась).

О том, как прочитать данные из Session::session_data, можно прочитать в этой статье. Сразу отмечу, что PHP самостоятельно выполняет восстановление данных, которые ему передаются функцией SessionManager::read(), просто иногда бывают ситуации, когда сессию нужно восстановить вручную (подпатчить на лету).

При более глубоком изучении вопроса также будет полезна эта замечательная статья.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Недавно мне пришлось столкнуться с задачей перевода базы данных из одного charset в другой. Исходная база была в iso-8859-1, предстояло перевести её в utf-8. Задача усложнялась тем, что в исходной базе присутствовали символы из других языков (русский, испанский и, возможно, китайский).

Погуляв по Интернету и поискав в Google, я нашёл несколько решений.

1. Способ, который мне очень понравился — TIP: Convert latin1 to UTF-8 in MySQL
   Вкратце (я немного изменил команды для повышения эффективности работы скрипта):
   mysqldump -uuser -ppassword --default-character-set=latin1 -n -K --skip-set-charset --skip-create-options --skip-extended-insert --compatible=mysql40 --max_allowed_packet=64K dbname > latin_dump.sql
   iconv -f ISO-8859-1 -t UTF-8 latin_dump.sql > utf8_dump.sql
   mysql --max_allowed_packet=1M -uuser -ppassword --default-character-set=utf8 database_utf8 < utf8_dump.sql
   rm -f *.sql

   Идея состоит в том, что мы просто создаём дамп исходной базы, при этом указывая mysqldump, что никаких деклараций CHARSET и иже с ними указывать не надо, затем скармливаем полученный дамп iconv, который преобразует весь latin1 в utf8, а затем преобразованный файл отдаём mysql (при этом указываем, что charset по умолчанию у нас utf8).
   Из неприятного: не сработало Как оказалось, из-за того, что cPanel создал базу (которая database_utf8) с DEFAULT CHARSET latin1. К счастью, лечится просто:

   ALTER DATABASE `database_utf8` CHARACTER SET 'utf8';
   ALTER DATABASE `database_utf8` COLLATE 'utf8_general_ci';
2. Экзотика (ссылку, к сожалению, потерял): идея состоит в том, что каждый столбец (CHAR, VARCHAR, TEXT etc) преобразуется сначала в BLOB (при этом меняется только тип столбца и ничего более), а затем BLOB преобразуется в исходный тип, но уже с новым charset. Я как представлю себе, сколько там менять…
3. Супер экзотика: Turning MySQL data in latin1 to utf8 utf-8. Без комментариев Видимо, человеку очень надо было преобразовать базу

И на закуску самый простой метод:

ALTER TABLE `table_name` CONVERT TO CHARACTER SET 'utf8';

Ибо как сказано в официальной документации:

If you want to change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this:

ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;

For a column that has a data type of VARCHAR or one of the TEXT types, CONVERT TO CHARACTER SET will change the data type as necessary to ensure that the new column is long enough to store as many characters as the original column. For example, a TEXT column has two length bytes, which store the byte-length of values in the column, up to a maximum of 65,535. For a latin1 TEXT column, each character requires a single byte, so the column can store up to 65,535 characters. If the column is converted to utf8, each character might require up to 3 bytes, for a maximum possible length of 3 × 65,535 = 196,605 bytes. That length will not fit in a TEXT column's length bytes, so MySQL will convert the data type to MEDIUMTEXT, which is the smallest string type for which the length bytes can record a value of 196,605. Similarly, a VARCHAR column might be converted to MEDIUMTEXT.

А мораль такова: если ничего не получается, прочтите, наконец, документацию!

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.