Я должен использовать подготовленные операторы для MySQL в МУДРОМ ПРОИЗВОДИТЕЛЬНОСТЬЮ PHP?

Я понимаю преимущества безопасности подготовленных операторов в MySQL. Никакая потребность затронуть ту тему здесь. Я задаюсь вопросом об аспекте производительности их.

Теперь, я знаю, когда запрос с помощью подготовленного оператора выполняется дважды в единственном Сценарии PHP, это быстрее, потому что запрос только анализируется однажды, однажды для каждого запроса. Клиент совершает одну поездку для подготовки, затем отправляет данные дважды с помощью протокола двоичной синхронной передачи данных. Протокол двоичной синхронной передачи данных быстрее, и Вы не получаете удар необходимости проанализировать во второй раз.

Однако что относительно случая, где я только хочу выполнить запрос однажды в единственном Сценарии PHP? Казалось бы, что использование подготовленного оператора хуже, потому что Вы совершаете две поездки в сервер, однажды для подготовки, и однажды отправить данные. Преимущество только необходимости проанализировать однажды потеряно, и Вы оштрафованы за то второе прохождение. Если данные не достаточно меньше в двоичном формате, Вы проигрываете при помощи подготовленного оператора, правильно?

Однако я прочитал некоторые противоречивые сведения о том, что делают mysqli PHP или библиотеки PDO? Действительно ли любой из них кэширует подготовленный оператор через выполнение сценария? Сервер оказывается перед необходимостью анализировать подготовленный оператор снова на последующем pageload или нет? Если ответ не, что оператор не должен быть проанализирован на втором pageload, то казалось бы, что подготовленные операторы ARE лучше, даже если Вы только выполняете запрос однажды на pageload.

Учтите, изменилось ли что-нибудь между версиями MySQL относительно этого. Можно безопасно предположить, что я использую PHP 5.2

Править: Только для прояснения я хочу ответ для MySQL и PHP а именно, указывая версию MySQL и если это когда-либо отличалось, и ТОЛЬКО рассматривать производительность, не простоту использования или безопасность.

ОБНОВЛЕНИЕ: Я принял ответ, который я сделал из-за развить комментария, имел несколько хороших идей. Я все еще немного разочарован, что никто, кажется, не может ответить на затруднение фактического вопроса, который я задал с любой уверенностью. Я иногда предполагаю, что ответ действительно, "он зависит".

22
задан Mike Sherov 9 February 2010 в 21:55
поделиться

3 ответа

История

Это был мой первый ответ на Stackoverflow. С тех пор многое изменилось, особенно отказ от поддержки mysql API и его удаление. Даже если вы все еще используете php 5.6, api mysql_ * использовать не следует. Теперь можно выбрать только PDO или mysqli. PDO лучше по многим причинам.

Кэшируются ли подготовленные операторы при загрузке страниц?

Я читал несколько противоречивых отчетов о том, что делают библиотеки PHP mysqli или PDO ? Кэширует ли какой-либо из них подготовленный оператор при выполнении скрипта ?

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

Для больших вставок (тысячи строк) большего прироста, вероятно, можно добиться, выгрузив данные в текстовый файл и загрузив его с помощью команды ЗАГРУЗИТЬ ДАННЫЕ В ФАЙЛ. Это намного быстрее, чем серия вставок.

Исходный ответ

Дело в том, что иногда mysqli работает быстрее, а иногда - mysql api. Но разница действительно небольшая. Если вы посмотрите на любой из тестов производительности в Интернете, разница действительно составляет всего 10-20 миллисекунд. Лучший способ повысить производительность - оптимизировать дизайн таблицы.

Многие тесты, которые «доказывают», что старый api работает быстрее, удобно забывают, что для максимальной безопасности mysql_real_escape_string () должен вызываться для каждой переменной, используемой в запросе.

Запросы кэшируются сервером тогда и только тогда, когда данные во всех таблицах, которые используются в запросе, остались неизменными.

Подождите еще одно обновление с фактическими номерами

12
ответ дан 29 November 2019 в 05:41
поделиться

Использование подготовленных операторов никогда не бывает плохой идеей. Я не использовал их в последнее время с mySQL, но я много использовал их с SQLSERVER - и они отлично работают.

Библиотека PDO, вероятно, не кэширует, но база данных будет делать это для подготовленного оператора.

К тому же, как вы сказали, они отлично подходят для обеспечения безопасности. Также очень приятно вытолкнуть эту логику из кода - вы не получите SQL, разбросанный по всему приложению.

0
ответ дан 29 November 2019 в 05:41
поделиться

Что именно вы имеете в виду под "обработкой на второй странице"?

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

Теперь я не могу спорить о подготовке + выполнении против простого запроса, с точки зрения производительности (мы/о повторяем запросы);

Но, чтобы спасти mysql от разбора сложного запроса в каждом отдельном выполнении скрипта, вы должны использовать хранимые процедуры; запрос будет просто CALL items(date,search_etc,id); вместо SELECT i.id FROM products as p JOIN item_prodct as t ON.... JOIN пункты как i... ON... ГДЕ ... p.date ... i.search_etc ...

Вы можете использовать сохраненные процедуры с подготовленными утверждениями.

0
ответ дан 29 November 2019 в 05:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: