PHP PDO: как повторная подготовка оператора влияет на производительность

Хорошо, так как я избивал методы ввода запросов для кеша, отличные от простого использования самой строки запроса, я сделал наивный тест. Ниже сравнивается использование простой строки запроса с первым созданием хэша md5:

$ php -v
$ PHP 5.3.0-3 with Suhosin-Patch (cli) (built: Aug 26 2009 08:01:52)
$ ...
$ php benchmark.php
$ PHP hashing: 0.19465494155884 [microtime]
$ MD5 hashing: 0.57781004905701 [microtime]
$ 799994

Код:

<?php
error_reporting(E_ALL);

$queries = array("SELECT",
                 "INSERT",
                 "UPDATE",
                 "DELETE",
                 );
$query_length = 256;
$num_queries  = 256;
$iter = 10000;

for ($i = 0; $i < $num_queries; $i++) {
    $q = implode('',
           array_map("chr",
             array_map("rand",
                       array_fill(0, $query_length, ord("a")),
                       array_fill(0, $query_length, ord("z")))));
    $queries[] = $q;
}

echo count($queries), "\n";

$cache = array();
$side_effect1 = 0;
$t = microtime(true);
for ($i = 0; $i < $iter; $i++) {
    foreach ($queries as $q) {
        if (!isset($cache[$q])) {
            $cache[$q] = $q;
        }
        else {
            $side_effect1++;
        }
    }
}
echo microtime(true) - $t, "\n";

$cache = array();
$side_effect2 = 0;
$t = microtime(true);
for ($i = 0; $i < $iter; $i++) {
    foreach ($queries as $q) {
        $md5 = md5($q);
        if (!isset($cache[$md5])) {
            $cache[$md5] = $q;
        }
        else {
            $side_effect2++;
        }
    }
}
echo microtime(true) - $t, "\n";

echo $side_effect1 + $side_effect2, "\n";

MySQL (как и большинство СУБД) кэширует планы выполнения для подготовленных операторов, поэтому, если пользователь А создает план для:

SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2

(где v1 и v2 являются переменными привязки), затем отправляет значения для интерполяции СУБД, затем пользователь B отправляет тот же запрос (но с другими значениями для интерполяции), СУБД не нужно повторно генерировать план. то есть именно СУБД находит соответствующий план, а не PDO.

Однако это означает, что для каждой операции с базой данных требуется по крайней мере 2 цикла обмена (1-й для представления запроса, второй для представления переменных связывания), в отличие от одного цикла для запроса с литеральными значениями, тогда это приводит к дополнительным сетевым затратам. . Также есть небольшие затраты на разыменование (и поддержку) кэша запросов/планов.

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

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

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

Поверьте мне, я делал это до и после создания кеша подготовленных операторов, прирост производительности был очень заметным - см. этот вопрос: Подготовка операторов SQL с PDO.

Это был код, который я придумал, с кэшированными подготовленными операторами:

function DB($query)
{
    static $db = null;
    static $result = array();

    if (is_null($db) === true)
    {
        $db = new PDO('sqlite:' . $query, null, null, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING));
    }

    else if (is_a($db, 'PDO') === true)
    {
        $hash = md5($query);

        if (empty($result[$hash]) === true)
        {
            $result[$hash] = $db->prepare($query);
        }

        if (is_a($result[$hash], 'PDOStatement') === true)
        {
            if ($result[$hash]->execute(array_slice(func_get_args(), 1)) === true)
            {
                if (stripos($query, 'INSERT') === 0)
                {
                    return $db->lastInsertId();
                }

                else if (stripos($query, 'SELECT') === 0)
                {
                    return $result[$hash]->fetchAll(PDO::FETCH_ASSOC);
                }

                else if ((stripos($query, 'UPDATE') === 0) || (stripos($query, 'DELETE') === 0))
                {
                    return $result[$hash]->rowCount();
                }

                else if (stripos($query, 'REPLACE') === 0)
                {
                }

                return true;
            }
        }

        return false;
    }
}

Поскольку мне не нужно беспокоиться о коллизиях в запросах, я использовал md5() вместо sha1().

Насколько мне известно, PDO не использует повторно уже подготовленные операторы, поскольку он не анализирует запрос сам по себе, поэтому он не знает, является ли это одним и тем же запросом.

Если вы хотите создать кеш подготовленных запросов, самым простым способом imho будет md5-хеширование строки запроса и создание таблицы поиска.

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

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