mysql, обычные вставки и использование bind_param, в чем разница ??

Это быстрее в случае селекта и если база вообще знает, что такое подготовленный запрос. Я не очень понимаю, что это может дать при вставке данных.

если тебе нет разницы, и таблицы - InnoDB (хотя судя по твоим результатам - похоже на MyISAM), попробуй вырубить autocommit

> должно быть быстрее $db->query('insert into table(...) values(...)');

Cильно быстрее не будет. С prepared statement ты экономишь время на парсинг запроса. Парсинг одного INSERT'а - это мелочи по сравнению с записью в таблицу, обновлением индексов, и тд и тп. Prepared statement дает экономию если у тебя хитро закрученный SELECT.

> (time limit exidid 300 пришлось повысить max_execution_time) это как я понимаю сообщение от PHP? Ты сколько строчек вставляешь?

Если строчек много, можно попробовать оптимизировать с другой стороны - склеить в PHP один запрос вида

INSERT INTO table VALUES (....), (....), (....), .... (...);

и один его запустить, без prepared statement. Это может ускорить дело.

... но только такой multi-line INSERT не поддерживается на других DBMS, в частности PostgreSQL'ем.

спасибо что объяснили

INSERT INTO table VALUES (....), (....), (....), .... (...); - немного помогло


>Cильно быстрее не будет. С prepared statement ты экономишь время на >парсинг запроса. Парсинг одного INSERT'а - это мелочи по сравнению с >записью в таблицу, обновлением индексов, и тд и тп. Prepared statement >дает экономию если у тебя хитро закрученный SELECT.

если так то тогда я не пойму какой смысл вообще было делать
prepare statement for insert ?????

>какой смысл вообще было делать prepare statement for insert ?????

Что такое SQL-иньекция знаешь?

> если так то тогда я не пойму какой смысл вообще было делать prepare statement for insert ?????

1. см предыдущего оратора, sql injections

2. afair стандарт требует чтобы все возможные PREPARE'ились. Даже такие одноразовые как DROP TABLE и тд. Может кто-нибудь родит такую dbms, где будет какая-нибудь предобработка для INSERT'ов. Еще один довод в пользу единообразия - кроме INSERT, есть еще INSERT ... SELECT. В котором имеет смысл прооптимизировать SELECT-часть.

Теоретический пример - INSERT может приводить к вызову триггеров. А в триггере уже есть, что предобрабатывать перед запуском. Но это, как я говорю, теория. я не в курсе делают ли реально существующие dbms'ы предобработки в таких случаях.

вообще-то, если взять ,скажем, jdbc, где параметры типизированны, то это хороший метод борьбы с скл-инйекциями как минимум, и признак хорошего тона как как максимум.

Теоретически триггеры и хранимые процедуры хранятся уже скомпилированными и не требуют предварительного запуска оптимизатора.

в mysql хранимки не хранятся скомпиленными. и вьюшки, кажется, тоже. prepare хорошо использовать для

1) защиты от инъекций 2) увеличения производительности, когда один и тот же запрос выполняется много раз.

Еще отмечту, что вместо bind_params гораздо удобнее делать my $sth = $dbh->prepare(...); $sth->execute( $param1, $param2 )