PDO MySQL: Użyj PDO :: ATTR_EMULATE_PREPARES czy nie?

Oto, o czym do tej pory czytałem PDO::ATTR_EMULATE_PREPARES:

1. Przygotować emulacja PDO jest lepsza dla wydajności od MySQL ojczystym przygotować omija cache zapytań .
2. Natywne przygotowanie MySQL jest lepsze pod względem bezpieczeństwa (zapobiega iniekcji SQL) .
3. Natywne przygotowanie MySQL jest lepsze do raportowania błędów .

Nie wiem już, na ile prawdziwe są te stwierdzenia. Moim największym zmartwieniem przy wyborze interfejsu MySQL jest zapobieganie wstrzykiwaniu SQL. Drugi problem to wydajność.

Moja aplikacja używa obecnie proceduralnego MySQLi (bez przygotowanych instrukcji) i całkiem sporo wykorzystuje pamięć podręczną zapytań. Rzadko będzie ponownie wykorzystywać przygotowane oświadczenia w jednym wniosku. Rozpocząłem przechodzenie na PDO ze względu na wymienione parametry i bezpieczeństwo przygotowanych zestawień.

Używam MySQL 5.1.61iPHP 5.3.2

Powinienem pozostawić PDO::ATTR_EMULATE_PREPARESwłączony czy nie? Czy istnieje sposób, aby zarówno wydajność pamięci podręcznej zapytań, jak i bezpieczeństwo przygotowywanych instrukcji?

Aby odpowiedzieć na Twoje obawy:

1. MySQL> = 5.1.17 (lub> = 5.1.21 dla instrukcji PREPAREi EXECUTE) może używać przygotowanych instrukcji w pamięci podręcznej zapytań . Twoja wersja MySQL + PHP może więc używać przygotowanych instrukcji z pamięcią podręczną zapytań. Zwróć jednak uwagę na zastrzeżenia dotyczące buforowania wyników zapytań w dokumentacji MySQL. Istnieje wiele rodzajów zapytań, których nie można buforować lub które są bezużyteczne, mimo że są buforowane. Z mojego doświadczenia wynika, że ​​pamięć podręczna zapytań i tak nie jest często bardzo korzystna. Zapytania i schematy wymagają specjalnej konstrukcji, aby maksymalnie wykorzystać pamięć podręczną. Często buforowanie na poziomie aplikacji i tak jest konieczne na dłuższą metę.

2. Natywne przygotowania nie mają żadnego znaczenia dla bezpieczeństwa. Pseudo przygotowane instrukcje będą nadal unikały wartości parametrów zapytania, zostanie to po prostu wykonane w bibliotece PDO z ciągami znaków zamiast na serwerze MySQL przy użyciu protokołu binarnego. Innymi słowy, ten sam kod PDO będzie równie podatny (lub niewrażliwy) na ataki polegające na wstrzykiwaniu, niezależnie od EMULATE_PREPARESustawień. Jedyna różnica polega na tym, gdzie następuje zamiana parametru - w przypadku EMULATE_PREPARES, w bibliotece PDO; bez EMULATE_PREPARES, występuje na serwerze MySQL.

3. Bez EMULATE_PREPARESciebie mogą pojawić się błędy składniowe w czasie przygotowania, a nie w czasie wykonywania; z EMULATE_PREPARESwas dostanie tylko błędy składniowe w czasie wykonywania, ponieważ PDO nie posiada zapytanie dać MySQL aż do czasu wykonania. Zauważ, że ma to wpływ na kod, który napiszesz ! Zwłaszcza jeśli używasz PDO::ERRMODE_EXCEPTION!

Dodatkowa uwaga:

• Koszt a prepare()(przy użyciu przygotowanych instrukcji przygotowanych natywnie) prepare();execute()może być trochę wolniejszy niż wysyłanie zwykłego zapytania tekstowego przy użyciu emulowanych gotowych instrukcji. W wielu systemach baz danych plan zapytań dla a prepare()jest również buforowany i może być współdzielony z wieloma połączeniami, ale nie sądzę, aby MySQL to robił. Jeśli więc nie użyjesz ponownie przygotowanego obiektu instrukcji do wielu zapytań, ogólne wykonanie może być wolniejsze.

Na koniec uważam, że przy starszych wersjach MySQL + PHP należy emulować przygotowane instrukcje, ale w przypadku najnowszych wersji należy wyłączyć emulację.

Po napisaniu kilku aplikacji korzystających z PDO stworzyłem funkcję połączenia PDO, która ma, moim zdaniem, najlepsze ustawienia. Prawdopodobnie powinieneś użyć czegoś takiego lub dostosować preferowane ustawienia:

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

Uważaj na wyłączanie PDO::ATTR_EMULATE_PREPARES(włączanie natywnych przygotowań), gdy PHP pdo_mysqlnie jest kompilowane mysqlnd.

Ponieważ stary libmysqlnie jest w pełni kompatybilny z niektórymi funkcjami, może prowadzić do dziwnych błędów, na przykład:

1. Utrata najbardziej znaczących bitów dla 64-bitowych liczb całkowitych podczas wiązania jako PDO::PARAM_INT(0x12345678AB zostanie przycięte do 0x345678AB na komputerze 64-bitowym)
2. Brak możliwości tworzenia prostych zapytań, takich jak LOCK TABLES(zgłasza SQLSTATE[HY000]: General error: 2030 This command is not supported in the prepared statement protocol yetwyjątek)
3. Musisz pobrać wszystkie wiersze z wyniku lub zamknąć kursor przed następnym zapytaniem (z mysqlndlub emulowanym przygotowuje, automatycznie robi to za Ciebie i nie traci synchronizacji z serwerem mysql)

Te błędy znalazłem w moim prostym projekcie po migracji na inny serwer, który był używany libmysqldla pdo_mysqlmodułu. Może jest znacznie więcej błędów, nie wiem. Testowałem również na świeżej, 64-bitowej wersji debian jessie, wszystkie wymienione błędy pojawiają się, gdy ja apt-get install php5-mysql, i znikają, gdy ja apt-get install php5-mysqlnd.

Kiedy PDO::ATTR_EMULATE_PREPARESjest ustawione na true (domyślnie) - te błędy i tak się nie zdarzają, ponieważ PDO w ogóle nie używa przygotowanych instrukcji w tym trybie. Tak więc, jeśli używasz w pdo_mysqloparciu o libmysql(podciąg "mysqlnd" nie pojawia się w polu "Wersja API klienta" w pdo_mysqlsekcji phpinfo) - nie powinieneś go PDO::ATTR_EMULATE_PREPARESwyłączać.

Wyłączyłbym emulację przygotowań, gdy używasz 5.1, co oznacza, że ​​PDO będzie korzystać z natywnej funkcji przygotowanych instrukcji.

PDO_MYSQL będzie korzystać z natywnej obsługi przygotowanych instrukcji obecnych w MySQL 4.1 i nowszych. Jeśli używasz starszej wersji bibliotek klienta mysql, PDO będzie je emulować.

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

Porzuciłem MySQLi na rzecz PDO ze względu na przygotowane nazwane instrukcje i lepsze API.

Aby jednak zachować równowagę, PDO działa pomijalnie wolniej niż MySQLi, ale warto o tym pamiętać. Wiedziałem o tym, kiedy dokonałem wyboru i zdecydowałem, że lepsze API i użycie standardu branżowego jest ważniejsze niż użycie pomijalnie szybszej biblioteki, która wiąże Cię z określonym silnikiem. FWIW Myślę, że zespół PHP również przychylnie patrzy na PDO zamiast MySQLi w przyszłości.

Polecam włączenie prawdziwych PREPAREwywołań bazy danych, ponieważ emulacja nie przechwytuje wszystkiego ... na przykład się przygotuje INSERT;!

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

Wyjście

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

Chętnie wezmę wydajność dla kodu, który faktycznie działa.

FWIW

Wersja PHP: PHP 5.4.9-4ubuntu2.4 (cli)

Wersja MySQL: 5.5.34-0ubuntu0

Jestem zaskoczony, że nikt nie wymienił jednego z największych powodów, dla których warto wyłączyć emulację. Przy włączonej emulacji PDO zwraca wszystkie liczby całkowite i zmiennoprzecinkowe jako łańcuchy . Po wyłączeniu emulacji liczby całkowite i zmiennoprzecinkowe w MySQL stają się liczbami całkowitymi i zmiennoprzecinkowymi w PHP.

Aby uzyskać więcej informacji, zapoznaj się z zaakceptowaną odpowiedzią na to pytanie: PHP + PDO + MySQL: jak zwrócić kolumny całkowite i liczbowe z MySQL jako liczby całkowite i liczby w PHP? .

Po co zmieniać emulację na „fałsz”?

Głównym tego powodem jest fakt, że przygotowanie bazy danych przez silnik bazy danych zamiast PDO polega na tym, że zapytanie i rzeczywiste dane są przesyłane oddzielnie, co zwiększa bezpieczeństwo. Oznacza to, że gdy parametry są przekazywane do zapytania, próby wstrzyknięcia do nich SQL są blokowane, ponieważ przygotowane przez MySQL instrukcje są ograniczone do pojedynczego zapytania. Oznacza to, że prawdziwie przygotowana instrukcja zakończy się niepowodzeniem po przekazaniu drugiego zapytania w parametrze.

Głównym argumentem przeciwko używaniu silnika bazy danych do przygotowania vs PDO są dwie wizyty na serwerze - jedna w celu przygotowania, a druga w celu przekazania parametrów - ale myślę, że dodatkowe zabezpieczenia są tego warte. Ponadto, przynajmniej w przypadku MySQL, buforowanie zapytań nie było problemem od wersji 5.1.

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

Tak dla porządku

PDO :: ATTR_EMULATE_PREPARES = true

Może to spowodować nieprzyjemny efekt uboczny. Może zwrócić wartości int jako ciąg.

PHP 7.4, pdo z mysqlnd.

Uruchamianie zapytania z PDO :: ATTR_EMULATE_PREPARES = true

Kolumna: id
Typ: liczba całkowita
Wartość: 1

Uruchamianie zapytania z PDO :: ATTR_EMULATE_PREPARES = false

Kolumna: identyfikator
Typ: ciąg
Wartość: „1”

W każdym przypadku wartości dziesiętne są zawsze zwracane jako ciąg znaków, niezależnie od konfiguracji :-(