mysql: записывать запрос определенных таблиц в таблицу аудита, временно включив general_log

Question

Я хочу регистрировать запросы INSERT, выполненные в определенной таблице, временно включив general_log с помощью триггеров. Мой подход состоит в том, чтобы сначала создать таблицу аудита:

CREATE TABLE AuditLog (
  id int auto_increment primary key,
  user_host varchar(255),
  event_time timestamp,
  query_executed varchar(1024)
)

Я хочу контролировать вставки на MyTable. Я создал две триггерные функции на MyTable. Тот, который выполняется перед операторами вставки, чтобы включить general_log:

CREATE TRIGGER enableGeneralLog BEFORE INSERT ON MyTable FOR EACH ROW
BEGIN
  SET GLOBAL general_log = 'ON'
END

И один триггер, который срабатывает после оператора вставки. Этот триггер собирает запрос на вставку из журнала general_log:

CREATE TRIGGER writeToAuditTable AFTER INSERT ON MyTable FOR EACH ROW
BEGIN
  INSERT INTO AuditLog (user_host, event_time, query_executed)
  SELECT
    user_host, event_time, query_executed
  FROM
    mysql.general_log
  WHERE
    argument LIKE '%INSERT INTO%'
    AND thread_id = connection_id()
  ORDER BY
    event_time DESC
  LIMIT 0,1;

  SET GLOBAL general_log = 'OFF'
END

После выполнения инструкции вставки на MyTable то AuditTableпусто. Проблема в том, что фактический запрос вставки на MyTable не регистрируется в general_log:

SELECT * FROM mysql.general_log # returns 1 row and not 2 as I expect

На выходе я вижу INSERT INTO AuditLog ...запрос, но ничего больше. Мне кажется, что фактический оператор вставки выполняется либо до, либо после триггеров. Что я делаю неправильно?

Я попытался пропустить первый триггер и включить general_log глобально и запустить вставку со вторым триггером - это работает. Однако наша БД записывает более 10 миллионов событий в журнал general_log в день, и это невозможно, так как хранилище растет слишком быстро.

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