Стоит ли использовать эти настройки для pdo?

Question

[Chesterfield25]

Стоит ли использовать такие настройки для pdo?

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Немного погуглив выяснил что

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

лучше не использовать.

Что подскажите знатоки?

Answer 1

[FanatPHP]

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

Comments

[Chesterfield25]

Первая в целом без разницы, но я предпочитаю использовать, чтобы передавать параметры в LIMIT без геморроя

Со значением false или true?

[FanatPHP]

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

Answer 2

[Vitsliputsli]

Немного погуглив выяснил что
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
лучше не использовать.

Да, лучше, если подразумевается вообще не указывать. PDO сам выберет лучшую настройку для конкретной СУБД.

Comments

[FanatPHP]

Ой, вот на это надеяться не стоит

[Vitsliputsli]

FanatPHP, дело не в надежде, просто если не уверен, то лучше положиться на PDO. К примеру в MySQL будет включена эмуляция, а в PsotgreSQL будут использоваться натуральные подготовленные выражения.

[FanatPHP]

Вот об этом я и говорю. Не стоит надеяться, что отключенная эмуляция для MySQL будет лучшей настройкой

[Vitsliputsli]

FanatPHP, нет, не отключенная эмуляция, а выбор эмуляции по дефолту, когда эта настройка не указывается.
Для MySQL по дефолту PDO выберет эмуляцию, что логично с очень странной реализацией подготовленных выражений в MySQL, а вот для PostgreSQL PDO выберет натуральные подготовленные выражения, что тоже логично, т.к. последняя СУБД не имеет проблем с ними.

[FanatPHP]

MySQL не имеет никаких проблем с реализацией подготовленных выражений, это какие-то фантазии
во всем мире сайты прекрасно работают с отключенной эмуляцией, и только у Vitsliputsli какие-то проблемы

[Vitsliputsli]

FanatPHP, а вы попробуйте замерить производительность без эмуляции и с эмуляцией, как минимум 13% MySQL кудато растерял когда данные отделены от запроса. А на PostgreSQL таких проблем нет.
Поэтому PDO для MySQL выбирает эмуляцию, а для PosgreSQL настоящие подготовленные выражения.
А работать будет, можно еще чего-нибудь повключать/поотключать и тоже работать будет.

[FanatPHP]

При настоящих в любом будет падение, поскольку требуется два обращения в БД на запрос
Через какую базу его не не делай.

[Vitsliputsli]

FanatPHP, да, но если исключить сетевой лаг (взять локальные СУБД), в PosgreSQL это падение не заметно в отличии от MySQL.

[FanatPHP]

А есть какие-то свидетельства такому странному поведению?

[Vitsliputsli]

FanatPHP, кабы было чтото еще, то не скрывал бы. Пока вижу только это странное поведение и интересный выбор дефолтных значений в PDO, вероятно с ним связанный. Ничего более не нашел, когда искал.

[FanatPHP]

я не про что-то еще а про цифру в 13%.
откуда дровишки?
или как всегда "кривыми руками цикл на 100500 пустых итераций, я гений нагрузочного тестирования"?

[Vitsliputsli]

FanatPHP, ага, кривыми руками, которые видно, то распрямляются, то скривляются.

При настоящих в любом будет падение, поскольку требуется два обращения в БД на запрос

и там не 2 обращения

[FanatPHP]

оооо, вечер перестаёт быть томным

и там не 2 обращения

а сколько?

[Vitsliputsli]

FanatPHP, блин, опять тот же вопрос. Почитай доку, что я пишу, похоже не запоминается.

[FanatPHP]

прочитал, там написано про два обращения, одно на prepare второе на execute.
откуда там больше (или меньше)?

[Vitsliputsli]

FanatPHP, а deallocate куда делся? Ты же сам статью писал про prepared statments и в том числе про запросы.

[FanatPHP]

Мда, про закрытие я не подумал, всегда упускаю его из виду.