PDO MySQL: ¿Usa PDO :: ATTR_EMULATE_PREPARES o no?

Esto es lo que he leído hasta ahora PDO::ATTR_EMULATE_PREPARES:

1. La emulación de preparación de PDO es mejor para el rendimiento, ya que la preparación nativa de MySQL evita la caché de consultas .
2. La preparación nativa de MySQL es mejor para la seguridad (evitando la inyección de SQL) .
3. La preparación nativa de MySQL es mejor para la notificación de errores .

Ya no sé qué tan cierta es ninguna de estas declaraciones. Mi mayor preocupación al elegir una interfaz MySQL es evitar la inyección de SQL. La segunda preocupación es el rendimiento.

Mi aplicación utiliza actualmente MySQLi procedimental (sin declaraciones preparadas) y utiliza bastante la caché de consultas. Rara vez reutilizará declaraciones preparadas en una sola solicitud. Comencé a moverme a PDO para los parámetros con nombre y la seguridad de las declaraciones preparadas.

Estoy usando MySQL 5.1.61yPHP 5.3.2

¿Debo dejar PDO::ATTR_EMULATE_PREPAREShabilitado o no? ¿Hay alguna manera de tener tanto el rendimiento de la caché de consultas como la seguridad de las declaraciones preparadas?

Para responder a sus inquietudes:

1. MySQL> = 5.1.17 (o> = 5.1.21 para las declaraciones PREPAREy EXECUTE) puede usar declaraciones preparadas en la caché de consultas . Entonces, su versión de MySQL + PHP puede usar declaraciones preparadas con la caché de consultas. Sin embargo, tenga en cuenta las advertencias para almacenar en caché los resultados de las consultas en la documentación de MySQL. Hay muchos tipos de consultas que no se pueden almacenar en caché o que son inútiles aunque estén en caché. En mi experiencia, la caché de consultas no suele ser una gran ganancia de todos modos. Las consultas y los esquemas necesitan una construcción especial para aprovechar al máximo la caché. A menudo, el almacenamiento en caché a nivel de aplicación termina siendo necesario de todos modos a largo plazo.

2. Native se prepara no hace ninguna diferencia para la seguridad. Las declaraciones pseudopreparadas aún escaparán de los valores de los parámetros de consulta, solo se hará en la biblioteca PDO con cadenas en lugar de en el servidor MySQL utilizando el protocolo binario. En otras palabras, el mismo código PDO será igualmente vulnerable (o no vulnerable) a los ataques de inyección independientemente de su EMULATE_PREPARESconfiguración. La única diferencia es dónde se produce el reemplazo del parámetro, con EMULATE_PREPARES, ocurre en la biblioteca PDO; sin EMULATE_PREPARES, ocurre en el servidor MySQL.

3. Sin EMULATE_PREPARESél, puede obtener errores de sintaxis en el tiempo de preparación en lugar de en el tiempo de ejecución; con EMULATE_PREPARES, solo obtendrá errores de sintaxis en el momento de la ejecución porque PDO no tiene una consulta para entregar a MySQL hasta el momento de la ejecución. ¡Tenga en cuenta que esto afecta el código que escribirá ! ¡Especialmente si estás usando PDO::ERRMODE_EXCEPTION!

Una consideración adicional:

• Hay un costo fijo para a prepare()(usando declaraciones preparadas nativas), por lo queprepare();execute() con declaraciones preparadas nativas puede ser un poco más lento que emitir una consulta de texto sin formato usando declaraciones preparadas emuladas. En muchos sistemas de bases de datos, el plan de consulta para a también prepare()se almacena en caché y puede compartirse con múltiples conexiones, pero no creo que MySQL haga esto. Entonces, si no reutiliza su objeto de declaración preparado para múltiples consultas, su ejecución general puede ser más lenta.

Como recomendación final , creo que con versiones anteriores de MySQL + PHP, debería emular declaraciones preparadas, pero con sus versiones más recientes debería desactivar la emulación.

Después de escribir algunas aplicaciones que usan PDO, he creado una función de conexión PDO que tiene lo que creo que son las mejores configuraciones. Probablemente debería usar algo como esto o ajustar su configuración preferida:

/**
 * Return PDO handle for a MySQL connection using supplied settings
 *
 * Tries to do the right thing with different php and mysql versions.
 *
 * @param array $settings with keys: host, port, unix_socket, dbname, charset, user, pass. Some may be omitted or NULL.
 * @return PDO
 * @author Francis Avila
 */
function connect_PDO($settings)
{
    $emulate_prepares_below_version = '5.1.17';

    $dsndefaults = array_fill_keys(array('host', 'port', 'unix_socket', 'dbname', 'charset'), null);
    $dsnarr = array_intersect_key($settings, $dsndefaults);
    $dsnarr += $dsndefaults;

    // connection options I like
    $options = array(
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
    );

    // connection charset handling for old php versions
    if ($dsnarr['charset'] and version_compare(PHP_VERSION, '5.3.6', '<')) {
        $options[PDO::MYSQL_ATTR_INIT_COMMAND] = 'SET NAMES '.$dsnarr['charset'];
    }
    $dsnpairs = array();
    foreach ($dsnarr as $k => $v) {
        if ($v===null) continue;
        $dsnpairs[] = "{$k}={$v}";
    }

    $dsn = 'mysql:'.implode(';', $dsnpairs);
    $dbh = new PDO($dsn, $settings['user'], $settings['pass'], $options);

    // Set prepared statement emulation depending on server version
    $serverversion = $dbh->getAttribute(PDO::ATTR_SERVER_VERSION);
    $emulate_prepares = (version_compare($serverversion, $emulate_prepares_below_version, '<'));
    $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, $emulate_prepares);

    return $dbh;
}

Tenga cuidado con la desactivación PDO::ATTR_EMULATE_PREPARES(activando la preparación nativa) cuando su PHP pdo_mysqlno está compilado contramysqlnd .

Como lo antiguo libmysqlno es totalmente compatible con algunas funciones, puede provocar errores extraños, por ejemplo:

1. Perder los bits más significativos para enteros de 64 bits cuando se vincula como PDO::PARAM_INT(0x12345678AB se recortará a 0x345678AB en una máquina de 64 bits)
2. Incapacidad para realizar consultas simples como LOCK TABLES(lanza una SQLSTATE[HY000]: General error: 2030 This command is not supported in the prepared statement protocol yetexcepción)
3. Necesita recuperar todas las filas del resultado o cerrar el cursor antes de la siguiente consulta (con mysqlndo emulado se prepara automáticamente hace esto por usted y no se desincroniza con el servidor mysql)

Estos errores los descubrí en mi proyecto simple cuando migré a otro servidor que usé libmysqlpara pdo_mysqlmodule. Quizás haya muchos más errores, no lo sé. También probé en debian jessie de 64 bits, todos los errores enumerados ocurren cuando yo apt-get install php5-mysql, y desaparecen cuandoapt-get install php5-mysqlnd .

Cuando PDO::ATTR_EMULATE_PREPARESse establece en verdadero (por defecto): estos errores no ocurren de todos modos, porque PDO no usa declaraciones preparadas en absoluto en este modo. Por lo tanto, si usa la subcadena pdo_mysqlbasada en libmysql(la subcadena "mysqlnd" no aparece en el campo de la pdo_mysqlsección "Versión de la API del cliente" en phpinfo), no debe PDO::ATTR_EMULATE_PREPARESapagar.

Desactivaría emular prepares mientras ejecuta 5.1, lo que significa que PDO aprovechará la funcionalidad de declaración preparada nativa.

PDO_MYSQL aprovechará el soporte nativo de declaraciones preparadas presente en MySQL 4.1 y superior. Si está utilizando una versión anterior de las bibliotecas cliente de mysql, PDO las emulará por usted.

http://php.net/manual/en/ref.pdo-mysql.php

Dejé MySQLi para PDO por las declaraciones con nombre preparadas y la mejor API.

Sin embargo, para equilibrarlo, PDO se comporta insignificantemente más lento que MySQLi, pero es algo a tener en cuenta. Lo supe cuando tomé la decisión y decidí que una mejor API y el uso del estándar de la industria era más importante que usar una biblioteca insignificantemente más rápida que lo vincula a un motor en particular. FWIW Creo que el equipo de PHP también está mirando favorablemente a PDO sobre MySQLi para el futuro.

Recomendaría habilitar PREPAREllamadas a bases de datos reales ya que la emulación no captura todo ..., por ejemplo, ¡se preparará INSERT;!

var_dump($dbh->prepare('INSERT;'));
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
var_dump($dbh->prepare('INSERT;'));

La salida

object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(7) "INSERT;"
}
bool(false)

Con mucho gusto recibiré un golpe de rendimiento para el código que realmente funciona.

FWIW

Versión de PHP: PHP 5.4.9-4ubuntu2.4 (cli)

Versión de MySQL: 5.5.34-0ubuntu0

¿Por qué cambiar la emulación a 'falso'?

La razón principal de esto es que hacer que el motor de la base de datos realice la preparación en lugar de PDO es que la consulta y los datos reales se envían por separado, lo que aumenta la seguridad. Esto significa que cuando los parámetros se pasan a la consulta, los intentos de inyectar SQL en ellos se bloquean, ya que las declaraciones preparadas de MySQL se limitan a una sola consulta. Eso significa que una verdadera declaración preparada fallaría cuando se pasara una segunda consulta en un parámetro.

El principal argumento en contra del uso del motor de base de datos para la preparación frente a la PDO son los dos viajes al servidor, uno para la preparación y otro para que se pasen los parámetros, pero creo que la seguridad adicional vale la pena. Además, al menos en el caso de MySQL, el almacenamiento en caché de consultas no ha sido un problema desde la versión 5.1.

https://tech.michaelseiler.net/2016/07/04/dont-emulate-prepared-statements-pdo-mysql/

Me sorprende que nadie haya mencionado una de las principales razones para desactivar la emulación. Con la emulación activada, PDO devuelve todos los números enteros y flotantes como cadenas . Cuando desactiva la emulación, los números enteros y flotantes en MySQL se convierten en números enteros y flotantes en PHP.

Para obtener más información, consulte la respuesta aceptada para esta pregunta: PHP + PDO + MySQL: ¿cómo devuelvo columnas enteras y numéricas de MySQL como enteros y numéricos en PHP? .

Para el registro

PDO :: ATTR_EMULATE_PREPARES = verdadero

Podría generar un efecto secundario desagradable. Podría devolver valores int como cadena.

PHP 7.4, pdo con mysqlnd.

Ejecutando una consulta con PDO :: ATTR_EMULATE_PREPARES = true

Columna:
tipo de identificación : entero
Valor: 1

Ejecutando una consulta con PDO :: ATTR_EMULATE_PREPARES = false

Columna: id
Tipo: cadena
Valor: "1"

En cualquier caso, los valores decimales siempre se devuelven como una cadena, independientemente de la configuración :-(