Ars Longa, Vita Brevis » MySQL

Вложенные транзакции в PDO

Vladimir — Sat, 06 Aug 2011 07:21:34 +0000

Использование вложенных транзакций в MySQL и PostgreSQL с PDO

В PDO есть такая особенность: отсутствие поддержки вложенных транзакций.

Вложенные транзакции бывают весьма полезны: например, у нас есть два сервиса, которые могут взаимодействовать между собой. Сервис А начинает транзакцию, что-то делает, затем вызывает сервис Б, затем подтверждает транзакцию.

Может так случиться, что сервисы А и Б разрабатываются разными людьми и разработчик сервиса Б может не знать, что сервис А уже начал выполнение транзакции. Как следствие, при использовании PDO как только сервис Б попытается начать транзакцию, PDO выбросит исключение, предупреждающее о наличии активной транзакции.

Тем не менее, такие СУБД как MySQL и PostgreSQL поддерживают вложенные транзакции (о чём PDO не знает). Поэтому было бы неплохо добавить поддержку вложенных транзакций для данных СУБД в PDO.

Ниже приведена очень простая реализация поддержки вложенных транзакций в PDO:

class MyPDO extends PDO
{
protected static $_supported_drivers = array(
'mysql' => true,
'pgsql' => true,
);

protected $_nest_level = 0;

protected function nestedTransactionsSupported()
{
return !empty(self::$_supported_drivers[$this->getAttribute(PDO::ATTR_DRIVER_NAME)]);
}

public function beginTransaction()
{
if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::beginTransaction();
}
else {
$this->exec("SAVEPOINT LEVEL{$this->_nest_level}");
}

++$this->_nest_level;
}

public function commit()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::commit();
}
else {
$this->exec("RELEASE SAVEPOINT LEVEL{$this->_nest_level}");
}
}

public function rollBack()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::rollBack();
}
else {
$this->exec("ROLLBACK TO SAVEPOINT LEVEL{$this->_nest_level}");
}
}
}

Подводные камни: в MySQL есть такое понятие как неявное подтверждение транзакции (implicit commit). На практике это ломает уровень вложенности транзакций, поддерживаемый данной реализацией. С другой стороны, в web-приложениях редко возникает необходимость использования транзакций (тем более вложенных) там, где присутствуют операторы, вызывающие неявное подтверждение транзакции.

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

Блокировки транзакций InnoDB при удалении данных из таблицы

Vladimir — Sat, 05 Feb 2011 16:01:16 +0000

Lock wait timeout exceeded; try restarting transaction

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

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

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

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

CREATE TABLE log (
id BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
ymd INTEGER NOT NULL,
domain VARCHAR(255) NOT NULL,
vmta VARCHAR(255) NOT NULL,
ip VARCHAR(45) NOT NULL,
deliveries TINYINT UNSIGNED NOT NULL,
bounces TINYINT UNSIGNED NOT NULL,
transients TINYINT UNSIGNED NOT NULL,
pmta_bounces TINYINT UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

В таблицу заносятся данные о доставке сообщений — выполняется это триггерами 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 это выглядит примерно так:

CREATE PROCEDURE populate_stats_daily()
BEGIN
DECLARE max_id BIGINT UNSIGNED;

START TRANSACTION;
SELECT MAX(id) INTO max_id FROM log;
INSERT INTO stats_daily (ymd, domain, vmta, ip, deliveries, bounces, transients, pmta_bounces)
SELECT
ymd, domain, vmta, ip,
SUM(deliveries) AS deliveries, SUM(bounces) AS bounces,
SUM(transients) AS transients, SUM(pmta_bounces) AS pmta_bounces
FROM log
WHERE id <= max_id
GROUP BY ymd, domain, vmta, ip
ORDER BY NULL
ON DUPLICATE KEY UPDATE
deliveries = deliveries + VALUES(deliveries),
bounces = bounces + VALUES(bounces),
transients = transients + VALUES(transients),
pmta_bounces = pmta_bounces + VALUES(pmta_bounces);

DELETE FROM log WHERE id <= max_id;
COMMIT;
END

Проблема наступает при выполнении оператора 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.

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

BEGIN
DECLARE cnt BIGINT UNSIGNED;

/* ... */

REPEAT
START TRANSACTION;
DELETE FROM log WHERE processed = 1 LIMIT 1000;
SELECT ROW_COUNT() INTO cnt;
COMMIT;
UNTIL cnt = 0 END REPEAT;
END

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

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

Дельта-бэкапы баз данных

Vladimir — Tue, 28 Sep 2010 09:45:21 +0000

Разностное резервное копирование экономит дисковое пространство

На одном из серверов с большим числом пользователей у нас настроено автоматическое создание резервных копий баз данных — четыре раза в день. Стоит отметить, что размер сжатых резервных копий всех баз данных превышает 400 мегабайт. Таким образом, за один день на резервные копии баз данных уходит около двух гигабайт дискового пространства. Две недели — почти 30 гигабайт. Расточительство.

Для экономии места мы изобрели велосипед под названием «дельта-бэкап» (известный как разностный бэкап, differential backup) — мы храним одну полную резервную копию базы данных и список изменений.

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

Идея состоит в том, что недельные изменения в базе данных (дельта) гораздо меньше по размеру, чем полный дамп базы данных. В случае с блогом обычно так и есть, а в случае с форумом — как повезёт.

Привожу одно из возможных решений, возможно, что кому-то оно пригодится.

#! /bin/sh

BACKUPDIR=/var/backups/mysql
DATE=`date +%y%W%u-%y%m%d-%H%M%S`
DATE2=`date +%y%W`
MYSQL_USER="user"
MYSQL_PASS="pass"
MYSQLDUMP=/usr/bin/mysqldump --quote-names --skip-lock-tables --skip-comments --skip-extended-insert -u$MYSQL_USER -p$MYSQL_PASS

umask 077
databases=`mysql -u$MYSQL_USER -p$MYSQL_PASS -B -N -e 'SHOW DATABASES' | xargs`
for db in $databases; do
if [ "$db" != "information_schema" ]; then
echo "Backing up ${db}..."
$MYSQLDUMP "$db" | gzip -5 > ${BACKUPDIR}/${db}-${DATE}.sql.gz

files=`echo $BACKUPDIR/$db-$DATE2*.sql.gz`
base=""
for j in $files; do
if [ "$base" = "" ]; then
base=$j
else
fname=`basename "$j" .sql.gz`
zdiff -U1 -d $base $j | bzip2 -c -9 > $BACKUPDIR/$fname.diff.bz2
rm -f $j
fi
done
fi
done

Небуферизованные запросы: снижаем потребление памяти WordPress

Wandering Soul — Thu, 02 Sep 2010 17:48:38 +0000

Снижение пикового потребления памяти благодаря в два раза заменой одной функции

Пиковое потребление оперативной памяти WordPress можно снизить приблизительно два раза и практически бесплатно. В чём секрет? В использовании правильных функций для работы с базой данных.

Опытные программисты знают, что API MySQL предоставляет два варианта работы с результатом запроса:

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

Первому варианту соответствует использование функции PHP mysql_unbuffered_query(), второму — mysql_query().

WordPress использует именно второй вариант. Но специфика функции wpdb::query() такова, что, выполнив запрос, WordPress полностью читает ответ в переменную wpdb::last_result.

Таким образом, при выполнении запроса, возвращающего большой объём данных:

MySQL выделит память для временного буфера под весь результат запроса
WordPress создаст локальную копию результата запроса
После вызова mysql_result_free() временный буфер будет освобождён

В результате связка WordPress + MySQL съест в два раза больше памяти, чем нужно. Это особенно ощутимо на системах с небольшим количеством доступной оперативной памяти.

Лечение: в файле wp-includes/wp-db.php заменяем mysql_query на mysql_unbuffered_query.

Из бонусов: при использовании mysql_unbuffered_query() PHP будет получать данные по мере их доступности (во время выполнения запроса), в то время как при использовании mysql_query() пришлось бы ждать окончания выполнения запроса.

Использование небуферизованных запросов, судя по отзывам, очень сильно позволяет повысить производительность.

Исправление ошибки в INSERT INTO … SELECT в Kohana 3 при использовании конфигурации базы данных, отличной от default

Wandering Soul — Thu, 12 Aug 2010 07:40:55 +0000

Исправление короче описания

Ситуация: нужно выполнить запрос вида

INSERT INTO `table` (`col1`, `col2`) SELECT * FROM `table` WHERE `col1` <> 0;

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

Например:

// application/config/database.php
// Важно, чтобы в конфигурации default нельзя было подключиться к серверу
return array(
'test' => array(
'type' => 'mysql',
'connection' => array(
'hostname' => 'localhost',
'database' => 'test',
'username' => 'username',
'password' => 'password',
'persistent' => FALSE,
),
'table_prefix' => '',
'charset' => 'utf8',
'caching' => FALSE,
'profiling' => TRUE,
),
);
?>

// application/classes/controller/welcome.php

class Controller_Welcome extends Controller
{
public function action_index()
{
$this->request->response = DB::insert('test', array('col1', 'col2'))
->select(DB::select()->from('test')->where('column1', '<>', '0'))
->compile(Database::instance('test')) . "\n";
}
}

?>

Важно, чтобы правая часть условия в where() была строкой.

В результате если мы запустим проект, то получим что-то вида:

INSERT INTO `test` (`column1`, `column2`) ErrorException [ 2 ]: mysql_connect(): Access denied for user 'www-data'@'localhost' (using password: NO) ~ MODPATH/database/classes/kohana/database/mysql.php [ 56 ]

Связано это с особенностью реализации метода Kohana_Database_Query_Builder_Insert::compile():

public function compile(Database $db)
{
// Start an insertion query
$query = 'INSERT INTO '.$db->quote_table($this->_table);

// Не интересно
// …

if (is_array($this->_values))
{
// Не интересно
// …
$query .= 'VALUES '.implode(', ', $groups);
}
else
{
// Add the sub-query
$query .= (string) $this->_values;
}

return $query;
}

Строка $query .= (string) $this->_values; вызывает метод compile() для SELECT, но так как конфигурация базы данных не передаётся, используется конфигурация default.

Самое простое исправление очевидно: заменить строку

$query .= (string) $this->_values;

на

$query .= $this->_values->compile($db);

Тем не менее, если SELECT использует одну базу данных, а INSERT — другую, и при этом используются разные charset’ы (да, это не самое большое извращение — бывают и хуже), этого будет недостаточно. В этом случае нужно добавить дополнительный параметр в метод select(), указывающий, какую конфигурацию использовать. Требуемые изменения кода тривиальны, посему остаются упражнением интересующемуся читателю.

Поддержка JOIN в запросах DELETE для Kohana 3

Wandering Soul — Wed, 11 Aug 2010 10:48:13 +0000

Добавление поддержки multiple-table DELETE в Query Builder Kohana 3

Иногда бывает полезно выполнить удаление записей в нескольких связанных таблицах, благо синтаксис позволяет. Разумеется, есть такая вещь как каскадное удаление записей, но в случае с MySQL (а именно — таблицами MyISAM) на неё надеяться не приходится.

Модуль Database из Kohana 3 не умеет использовать JOIN с операцией DELETE. Нужно ему помочь.

class Database_Query_Builder_Delete extends Kohana_Database_Query_Builder_Delete
{
protected $_to_delete = array();
protected $_join = array();
protected $_last_join;

/**
* Adds addition tables to "JOIN ...".
*
* @param mixed column name or array($column, $alias) or object
* @param string join type (LEFT, RIGHT, INNER, etc)
* @return Database_Query_Builder_Delete
*/
public function join($table, $type = NULL)
{
$this->_join[] = $this->_last_join = new Database_Query_Builder_Join($table, $type);

return $this;
}

public function delete_table($table)
{
$this->_to_delete[] = $table;
}

/**
* Adds "ON ..." conditions for the last created JOIN statement.
*
* @param mixed column name or array($column, $alias) or object
* @param string logic operator
* @param mixed column name or array($column, $alias) or object
* @return $this
*/
public function on($c1, $op, $c2)
{
$this->_last_join->on($c1, $op, $c2);

return $this;
}

/**
* Compile the SQL query and return it.
*
* @param Database Database instance
* @return string
*/
public function compile(Database $db)
{
$query = 'DELETE';
if ($this->_to_delete) {
$query .= ' ' . join(', ', array_map(array($db, 'quote_identifier'), $this->_to_delete));
}

$query .= ' FROM ' . $db->quote_table($this->_table);

if ($this->_join) {
$query .= ' ' . $this->_compile_join($db, $this->_join);
}

if ($this->_where) {
$query .= ' WHERE ' . $this->_compile_conditions($db, $this->_where);
}

if (!$this->_join) {
if ($this->_order_by) {
$query .= ' ' . $this->_compile_order_by($db, $this->_order_by);
}

if ($this->_limit !== null) {
$query .= ' LIMIT ' . $this->_limit;
}
}
else {
throw new Kohana_Exception('Cannot use ORDER BY or LIMIT in a multiple-table DELETE');
}

return $query;
}

public function reset()
{
parent::reset();
$this->_to_delete = array();
$this->_join = array();
$this->_last_join = null;
}
}

?>

Данный класс добавляет функциональность, связанную с удалением данных из нескольких таблиц, в Query Builder. Использование покажу на примерах:

Запросу

DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3
WHERE t1.id=t2.id AND t2.id=t3.id;

соответствует код

DB::delete('t1')
->join('t2', 'INNER')
->on('t1.id', '=', 't2.id')
->join('t3', 'INNER')
->on('t2.id', '=', 't3.id')
->delete_table('t1')
->delete_table('t2');

Запросу

DELETE FROM t1 INNER JOIN t2 INNER JOIN t3
WHERE t1.id=t2.id AND t2.id=t3.id;

соответствует код

DB::delete('t1')
->join('t2', 'INNER')
->on('t1.id', '=', 't2.id')
->join('t3', 'INNER')
->on('t2.id', '=', 't3.id');

Как видим, метод Database_Query_Builder_Delete::delete_table() задаёт имена таблиц, которые нужно удалить; если данный метод не вызывать, будут удалены все таблицы, перечисленные в запросе.

SQLMon для Code Igniter

Vladimir — Sat, 13 Feb 2010 06:10:58 +0000

Мониторинг SQL-запросов в Code Igniter

На днях мне довелось заняться оптимизацией одного проекта, написанного с использованием фреймворка Code Igniter. Важной частью процесса являлась оптимизация запросов к базе данных, а для этого как минимум нужно видеть эти запросы перед глазами.

Этот минимум в Code Igniter достигается очень просто: вызовом

$this->output->enable_profiler(TRUE);

в контроллере. Но когда запросов на странице очень много, хотелось бы избавиться от рутинного выполнения EXPLAIN для каждого подозрительного запроса. Что, собственно, и делает SQLMon. Возникает логичное желание интегрировать его в Code Igniter.

Но в отличие от Kohana, с Code Igniter здесь не всё так просто. Во-первых, Code Igniter не поддерживает так называемую каскадную файловую систему. Во-вторых, Code Igniter не позволяет расширять или заменять класс Database. А изменять код системы (и поддерживать его при каждом обновлении) очень не хочется. Тем не менее, я нашел простое решение и реализовал соответствующую библиотеку.

Перед использованием библиотеки рекомендуется прочитать статью «Optimizing Queries with EXPLAIN».

Использование библиотеки. Библиотека состоит из двух частей:

Драйвер базы данных (каталог system/database/drivers/mysql_exp). Драйвер требует наличия драйвера MySQL (класс CI_DB_mysql_driver), так как, по сути дела, является производным от него классом. Драйвер переопределяет метод _execute(), в котором и выполняет анализ запроса.
Представление (view). Находится в каталоге system/application/views/sqlmon, используется для отображения результатов.

Установка библиотеки простая: содержимое каталога system/database должен быть скопировано в system/database, содержимое каталога system/application должно быть скопировано в каталог приложения. Затем нужно отредактировать настройки соединения с базой данных (файл appliaction/config/database.php): параметр dbdriver соединения нужно установить в mysql_exp.

Пример:

$active_group = "default";
$active_record = TRUE;

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "username";
$db['default']['password'] = "password";
$db['default']['database'] = "database";
$db['default']['dbdriver'] = "mysql_exp"; // <<< Вот оно
$db['default']['dbprefix'] = "mso_";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "system/cache/db";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

Затем в соответствующее представление добавляем код:

$ci = &get_instance();
$ci->load->view('sqlmon/sqlmon');
?>

И наслаждаемся. На выходе должно получиться что-то вида (на примере MaxSite CMS; изображение можно кликнуть):

Скачать SQLMon для Code Igniter.

SQLMon для Kohana 3

Vladimir — Tue, 09 Feb 2010 19:16:01 +0000

Мониторинг SQL-запросов в Kohana 3

Продолжая славную традицию реализации SQLMon под различные CMS/фреймворки, написал одному заказчику модуль для Kohana 3.

SQLMon для Kohana 3 интегрируется в иерархию классов Database (встраивается между классами Database_MySQL и Kohana_Database_MySQL) и реализует обёртку над методом Kohana_Database_MySQL::query(), измеряя время выполнения запроса, объём потребляемой памяти, записывая код ошибки запроса, трассу вызовов и EXPLAIN запроса (причём не только для SELECT, но и UPDATE/DELETE и INSERT/REPLACE INTO … AS или CREATE TABLE … AS) — всё то же самое, что и SQLMon для WordPress.

Данный модуль будет полезен разработчикам для анализа производительности запросов MySQL и поиска решений для их оптимизации. Перед использованием модуля рекомендуется прочитать статью «Optimizing Queries with EXPLAIN».

Использование модуля. Модуль должен быть распакован в каталог modules проекта (после распаковки появится каталог sqlmon). Затем модуль должен быть активирован в файле application/bootstrap.php. Очень важно, чтобы модуль подключался перед модулем database — это связано с особенностями поиска классов в Kohana 3.

Например:

Kohana::modules(array(
'sqlmon' => MODPATH.'sqlmon', // SQL Monitor — обязательно перед Database
'database' => MODPATH.'database', // Database access
'orm' => MODPATH.'orm', // Object Relationship Mapping
'pagination' => MODPATH.'pagination', // Paging of results
));

Для отображения статистики нужно выполнить

echo View::factory('sqlmon/sqlmon'); ?>

Результатом будет нечто вида (скриншот можно кликнуть):

Настройка. SQLMon использует файлы конфигурации модуля Database — config/database.php. Для контроля поведения SQLMon нужно использовать параметры:

backtrace — boolean (по умолчанию true) — должен ли SQLMon отображать трассу вызовов (то, что отображается синим цветом на скриншоте выше);
explain — boolean (по умолчанию true) — должен ли SQLMon отображать план выполнения запросов (EXPLAIN).

Пример файла конфигурации:

return array(
'default' => array(
'type' => 'mysql',
'profiling' => true,
'charset' => 'utf8',
'table_prefix' => '',
// Настройки SQLMon
'backtrace' => true,
'explain' => true,
// ---
'connection' => array(
'username' => 'root',
'password' => 'M1dn19ht',
'hostname' => 'localhost',
'persistent' => false,
'database' => 'feedfetcher'
),
)
);
?>

Скачать SQLMon для Kohana 3.

Ужасы таксономии в WordPress

Vladimir — Tue, 09 Jun 2009 01:01:42 +0000

12,000 запросов для удаления одной категории

Внутренняя реализация управления таксономиями в WordPress — это просто кошмар какой-то. Мало того, что код написан в процедурном стиле (использование ООП помогло бы решить некоторые проблемы с производительностью, которые иначе можно решить только глобальными переменными), он к тому же очень плохо масштабируется.

Я взял свежую дефолтную инсталляцию WordPress 2.8-bleeding, сгенерировал тестовый контент и пошел искать недоработки и проблемы с производительностью. Одну из них я нашел очень быстро: при попытке удалить категорию, в которой была 1,001 ~~ночь~~ запись.

На неслабом сервере это заняло около 20 секунд и… более 12,000 запросов (да-да, двенадцати тысяч, я количеством ноликов, увы, не ошибся).

Лог запросов (application/x-gzip, 75.1 КиБ)
Лог запросов (text/html, 2.5 МиБ)

А всё почему? Из-за одного магического foreach в wp_delete_term():

foreach ( (array) $objects as $object ) {
$terms = wp_get_object_terms($object, $taxonomy, 'fields=ids');
if ( 1 == count($terms) && isset($default) )
$terms = array($default);
else
$terms = array_diff($terms, array($term));
$terms = array_map('intval', $terms);
wp_set_object_terms($object, $terms, $taxonomy);
}

Куда уж проще: выбрать ID всех объектов, связанных с данной таксономией:

SELECT DISTINCT tr.object_id
FROM wp_term_taxonomy AS tt INNER JOIN wp_term_relationships AS tr USING(term_taxonomy_id)
WHERE tr.term_id = 'TERM ID HERE' AND tr.taxonomy = 'TAXONOMY NAME HERE'

Затем удалить терм к едрене фене и жукам майским:

DELETE
FROM wp_term_taxonomy AS tt LEFT JOIN wp_term_relationships AS tr USING(term_taxonomy_id)
WHERE tr.term_id = 'TERM ID HERE' AND tr.taxonomy = 'TAXONOMY NAME HERE'

Затем вставить дефолтное значение терма для тех объектов, которые выпали из таксономии: вычитаем из результата, полученного в первом запросе, результат запроса SELECT object_id FROM wp_term_relationship WHERE object_id IN ("список из первого запроса"). Для полученного результата выполнить один большой INSERT:

INSERT INTO wp_term_relationships VALUES
('OBJECT_ID_1', 'DEFAULT_TERM_TAXONOMY_ID', 0), /* ... */ ('OBJECT_ID_N', 'DEFAULT_TERM_TAXONOMY_ID', 0)

После чего сделать UPDATE wp_term_taxonomy SET `count` = `count` + 'количество строк, затронутых INSERT' WHERE term_taxonomy_id = 'DEFAULT_TERM_TAXONOMY_ID'.

Причём если дефолтное значение терма не задано, то достаточно просто одного DELETE.

В результате получаем пять запросов вместо 12,000, улучшенную производительность и меньше мусора. За кадром осталась очистка ~~инсулинового~~ кэша WordPress, но идея понятна. Вот только жаль, что оно увидит свет очень нескоро.

Увеличение производительности плагина NextGen Gallery

Vladimir — Sat, 06 Jun 2009 10:27:11 +0000

Добавляем необходимые индексы в таблицу

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

Проявляется это в том, что при отображении любой галереи MySQL приходится полностью сканировать таблицу wp_ngg_pictures.

Например:

EXPLAIN
SELECT SQL_CALC_FOUND_ROWS tt.*, t.*
FROM wp_ngg_gallery AS t INNER JOIN wp_ngg_pictures AS tt ON t.gid = tt.galleryid
WHERE t.gid = 3 AND tt.exclude<>1
ORDER BY tt.sortorder ASC

+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+
| 1 | SIMPLE | t | const | PRIMARY | PRIMARY | 8 | const | 1 | Using filesort |
| 1 | SIMPLE | tt | ALL | NULL | NULL | NULL | NULL | 11700 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+

Исправляется ситуация путём добавления ключа по столбцам galleryid и sortorder в таблицу wp_ngg_pictures:

ALTER TABLE `wp_ngg_pictures` ADD KEY (`galleryid`, `sortorder`)

После этого EXPLAIN покажет значительно лучшую картину:

+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+
| 1 | SIMPLE | t | const | PRIMARY | PRIMARY | 8 | const | 1 | |
| 1 | SIMPLE | tt | ref | galleryid | galleryid | 8 | const | 59 | Using where |
+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+

Как видим, использование правильного индекса позволяет избежать файловой сортировки; к тому же, из таблицы wp_ngg_pictures сразу выбираются только нужные данные (59 строк против 11,700 строк).