PDO MySQL: Use PDO :: ATTR_EMULATE_PREPARES ou não?

Isto é o que li até agora sobre PDO::ATTR_EMULATE_PREPARES:

1. A emulação de preparação do PDO é melhor para desempenho, pois a preparação nativa do MySQL ignora o cache de consulta .
2. A preparação nativa do MySQL é melhor para segurança (evitando injeção de SQL) .
3. A preparação nativa do MySQL é melhor para relatórios de erros .

Não sei mais o quão verdadeira qualquer uma dessas afirmações é. Minha maior preocupação ao escolher uma interface MySQL é prevenir a injeção de SQL. A segunda preocupação é o desempenho.

Meu aplicativo atualmente usa MySQLi procedural (sem instruções preparadas) e utiliza bastante o cache de consulta. Raramente reutilizará instruções preparadas em uma única solicitação. Comecei a mudança para PDO para os parâmetros nomeados e segurança das instruções preparadas.

Estou usando MySQL 5.1.61ePHP 5.3.2

Devo deixar PDO::ATTR_EMULATE_PREPARESativado ou não? Existe uma maneira de ter o desempenho do cache de consulta e a segurança das instruções preparadas?

Para responder às suas preocupações:

1. MySQL> = 5.1.17 (ou> = 5.1.21 para as instruções PREPAREe EXECUTE) pode usar instruções preparadas no cache de consulta . Portanto, sua versão do MySQL + PHP pode usar instruções preparadas com o cache de consulta. No entanto, observe cuidadosamente as advertências para os resultados das consultas em cache na documentação do MySQL. Existem muitos tipos de consultas que não podem ser armazenadas em cache ou que são inúteis, embora estejam armazenadas em cache. Na minha experiência, o cache de consulta geralmente não é uma grande vitória. Consultas e esquemas precisam de construção especial para aproveitar ao máximo o cache. Freqüentemente, o armazenamento em cache no nível do aplicativo acaba sendo necessário de qualquer maneira a longo prazo.

2. A preparação nativa não faz diferença para a segurança. As instruções pseudo-preparadas ainda escaparão dos valores dos parâmetros de consulta, isso apenas será feito na biblioteca PDO com strings em vez de no servidor MySQL usando o protocolo binário. Em outras palavras, o mesmo código PDO será igualmente vulnerável (ou não vulnerável) a ataques de injeção, independentemente de sua EMULATE_PREPARESconfiguração. A única diferença é onde ocorre a substituição do parâmetro - com EMULATE_PREPARES, ela ocorre na biblioteca PDO; sem EMULATE_PREPARES, ele ocorre no servidor MySQL.

3. Sem EMULATE_PREPARESvocê pode obter erros de sintaxe no tempo de preparação em vez de no tempo de execução; com EMULATE_PREPARESvocê só obterá erros de sintaxe em tempo de execução porque PDO não tem uma consulta para dar ao MySQL até o tempo de execução. Observe que isso afeta o código que você escreverá ! Especialmente se você estiver usando PDO::ERRMODE_EXCEPTION!

Uma consideração adicional:

• Há um custo fixo para a prepare()(usando instruções preparadas nativas), portanto, a prepare();execute()com instruções preparadas nativas pode ser um pouco mais lento do que emitir uma consulta de texto simples usando instruções preparadas emuladas. Em muitos sistemas de banco de dados, o plano de consulta para a também prepare()é armazenado em cache e pode ser compartilhado com várias conexões, mas não acho que o MySQL faça isso. Portanto, se você não reutilizar seu objeto de instrução preparado para várias consultas, sua execução geral pode ser mais lenta.

Como recomendação final , acho que com versões anteriores do MySQL + PHP, você deve emular instruções preparadas, mas com suas versões mais recentes você deve desligar a emulação.

Depois de escrever alguns aplicativos que usam PDO, fiz uma função de conexão PDO que tem o que considero ser as melhores configurações. Você provavelmente deve usar algo assim ou ajustar suas configurações preferidas:

/**
 * 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;
}

Cuidado ao desabilitar PDO::ATTR_EMULATE_PREPARES(ativar preparações nativas) quando seu PHP pdo_mysqlnão for compilado mysqlnd.

Como o antigo libmysqlnão é totalmente compatível com algumas funções, pode levar a bugs estranhos, por exemplo:

1. Perda de bits mais significativos para inteiros de 64 bits ao vincular como PDO::PARAM_INT(0x12345678AB será cortado para 0x345678AB na máquina de 64 bits)
2. Incapacidade de fazer consultas simples como LOCK TABLES(lança SQLSTATE[HY000]: General error: 2030 This command is not supported in the prepared statement protocol yetexceção)
3. Precisa buscar todas as linhas do resultado ou fechar o cursor antes da próxima consulta (com mysqlndou emulado prepara isso automaticamente faz este trabalho para você e não sai de sincronia com o servidor mysql)

Esses bugs descobri em meu projeto simples quando migrei para outro servidor que usava libmysqlpara o pdo_mysqlmódulo. Talvez haja muito mais bugs, não sei. Também testei no debian jessie de 64 bits fresco, todos os bugs listados ocorrem quando eu apt-get install php5-mysql, e desaparecem quando eu apt-get install php5-mysqlnd.

Quando PDO::ATTR_EMULATE_PREPARESé definido como verdadeiro (como padrão) - esses bugs não acontecem de qualquer maneira, porque o PDO não usa instruções preparadas neste modo. Portanto, se você usar o pdo_mysqlbaseado em libmysql(substring "mysqlnd" não aparece no campo "Versão da API do cliente" da pdo_mysqlseção no phpinfo) - você não deve PDO::ATTR_EMULATE_PREPARESdesligar.

Eu desligaria as preparações de emulação enquanto você está executando o 5.1, o que significa que o PDO aproveitará a funcionalidade de instrução preparada nativa.

PDO_MYSQL aproveitará a vantagem do suporte de instrução preparada nativa presente no MySQL 4.1 e superior. Se você estiver usando uma versão mais antiga das bibliotecas de cliente mysql, o PDO irá emulá-las para você.

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

Eu troquei o MySQLi pelo PDO para as declarações nomeadas preparadas e a melhor API.

No entanto, para ser equilibrado, o PDO tem um desempenho insignificante mais lento do que o MySQLi, mas é algo para se ter em mente. Eu sabia disso quando fiz a escolha e decidi que uma API melhor e usar o padrão da indústria era mais importante do que usar uma biblioteca desprezivelmente mais rápida que conecta você a um mecanismo específico. FWIW Acho que a equipe do PHP também está olhando favoravelmente para o PDO em vez do MySQLi para o futuro.

Eu recomendo habilitar PREPAREchamadas de banco de dados reais , pois a emulação não pega tudo .., por exemplo, ela irá preparar INSERT;!

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

A saída

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

Terei prazer em obter um impacto sobre o desempenho do código que realmente funciona.

FWIW

Versão do PHP: PHP 5.4.9-4ubuntu2.4 (cli)

Versão do MySQL: 5.5.34-0ubuntu0

Por que mudar a emulação para 'false'?

A principal razão para isso é que ter o mecanismo de banco de dados fazendo a preparação em vez de PDO é que a consulta e os dados reais são enviados separadamente, o que aumenta a segurança. Isso significa que quando os parâmetros são passados ​​para a consulta, as tentativas de injetar SQL neles são bloqueadas, uma vez que as instruções preparadas pelo MySQL são limitadas a uma única consulta. Isso significa que uma instrução preparada verdadeira falhará quando for passada uma segunda consulta em um parâmetro.

O principal argumento contra o uso do mecanismo de banco de dados para a preparação versus PDO são as duas viagens ao servidor - uma para a preparação e outra para os parâmetros serem passados ​​- mas acho que a segurança adicional vale a pena. Além disso, pelo menos no caso do MySQL, o cache de consulta não é um problema desde a versão 5.1.

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

Estou surpreso que ninguém tenha mencionado um dos maiores motivos para desativar a emulação. Com a emulação ativada, o PDO retorna todos os inteiros e flutuantes como strings . Quando você desativa a emulação, inteiros e flutuantes no MySQL tornam-se inteiros e flutuantes no PHP.

Para obter mais informações, consulte a resposta aceita para esta pergunta: PHP + PDO + MySQL: como faço para retornar colunas inteiras e numéricas do MySQL como inteiros e numéricos em PHP? .

Para o registro

PDO :: ATTR_EMULATE_PREPARES = true

Isso pode gerar um efeito colateral desagradável. Ele pode retornar valores inteiros como string.

PHP 7.4, pdo com mysqlnd.

Executando uma consulta com PDO :: ATTR_EMULATE_PREPARES = true

Coluna: id
Tipo: inteiro
Valor: 1

Executando uma consulta com PDO :: ATTR_EMULATE_PREPARES = false

Coluna: id
Tipo: string
Valor: "1"

Em qualquer caso, os valores decimais são sempre retornados como uma string, independentemente da configuração :-(