Syntax:
INSERT DELAYED ...

The DELAYED option for the INSERT statement is a MySQL extension to
standard SQL that is very useful if you have clients that cannot or
need not wait for the INSERT to complete. This is a common situation
when you use MySQL for logging and you also periodically run SELECT and
UPDATE statements that take a long time to complete.

When a client uses INSERT DELAYED, it gets an okay from the server at
once, and the row is queued to be inserted when the table is not in use
by any other thread.

Another major benefit of using INSERT DELAYED is that inserts from many
clients are bundled together and written in one block. This is much
faster than performing many separate inserts.

Note that INSERT DELAYED is slower than a normal INSERT if the table is
not otherwise in use. There is also the additional overhead for the
server to handle a separate thread for each table for which there are
delayed rows. This means that you should use INSERT DELAYED only when
you are really sure that you need it.

The queued rows are held only in memory until they are inserted into
the table. This means that if you terminate mysqld forcibly (for
example, with kill -9) or if mysqld dies unexpectedly, any queued rows
that have not been written to disk are lost.

There are some constraints on the use of DELAYED:

o INSERT DELAYED works only with MyISAM, MEMORY, ARCHIVE, and BLACKHOLE
  tables. For engines that do not support DELAYED, an error occurs.

o An error occurs for INSERT DELAYED if used with a table that has been
  locked with LOCK TABLES because the insert must be handled by a
  separate thread, not by the session that holds the lock.

o For MyISAM tables, if there are no free blocks in the middle of the
  data file, concurrent SELECT and INSERT statements are supported.
  Under these circumstances, you very seldom need to use INSERT DELAYED
  with MyISAM.

o INSERT DELAYED should be used only for INSERT statements that specify
  value lists. The server ignores DELAYED for INSERT ... SELECT or
  INSERT ... ON DUPLICATE KEY UPDATE statements.

o Because the INSERT DELAYED statement returns immediately, before the
  rows are inserted, you cannot use LAST_INSERT_ID() to get the
  AUTO_INCREMENT value that the statement might generate.

o DELAYED rows are not visible to SELECT statements until they actually
  have been inserted.

o Prior to MySQL 5.5.7, INSERT DELAYED was treated as a normal INSERT
  if the statement inserted multiple rows, binary logging was enabled,
  and the global logging format was statement-based (that is, whenever
  binlog_format was set to STATEMENT). Beginning with MySQL 5.5.7,
  INSERT DELAYED is always handled as a simple INSERT (that is, without
  the DELAYED option) whenever the value of binlog_format is STATEMENT
  or MIXED. (In the latter case, the statement no longer triggers a
  switch to row-based logging, and so is logged using the
  statement-based format.)

  This does not apply when using row-based binary logging mode
  (binlog_format set to ROW), in which INSERT DELAYED statements are
  always executed using the DELAYED option as specified, and logged as
  row-update events.

o DELAYED is ignored on slave replication servers, so that INSERT
  DELAYED is treated as a normal INSERT on slaves. This is because
  DELAYED could cause the slave to have different data than the master.

o Pending INSERT DELAYED statements are lost if a table is write locked
  and ALTER TABLE is used to modify the table structure.

o INSERT DELAYED is not supported for views.

o INSERT DELAYED is not supported for partitioned tables.

URL: https://mariadb.com/kb/en/insert-delayed/

