3

We have quite a few queries we consider "fire and forget".

In the sense that these are just logging inserts, updates and such. Things that are not as critical, and data from which is never used on the front end the users sees.

This sounds like an ideal case for mysql_unbuffered_query.

Is this advisable?

We are using innodb so using something like INSERT DELAYED is not possible.

Thanks!

citruspi
  • 6,709
  • 4
  • 27
  • 43
anonymous-one
  • 14,454
  • 18
  • 60
  • 84
  • Could you change the engine just for the logging table to MyISAM? – biziclop Jun 16 '12 at 19:57
  • The logging was just one example of a query we concider fire-and-forget. We would like to implement a fire-and-forget on a number of queries thru our code base. – anonymous-one Jun 17 '12 at 18:29

1 Answers1

1

After reading http://www.php.net/manual/en/mysqlinfo.concepts.buffering.php:

Following these characteristics buffered queries should be used in cases where you expect only a limited result set or need to know the amount of returned rows before reading all rows. Unbuffered mode should be used when you expect larger results.

Seem that unbuffered query are usefull only on select, because update, insert and delete have no result set.

I don't see any problem using unbuffered update, insert and delete except this:

Unless the full result set was fetched from the server no further queries can be sent over the same connection. Unbuffered queries can also be referred to as "use result".

So, are last_insert_id and affected_rows a result? I don't belive it, because no mysql_fetch* is done to get these infos.

So, if you experience an improve of performances using unbuffered query, use it!

Ivan Buttinoni
  • 4,110
  • 1
  • 24
  • 44