AUTO_INCREMENT requires a value when inserting, but only sometimes

Question

I am using MySQL (Percona 5.5.34-32.0) and I have this table;

mysql> SHOW CREATE TABLE privmsgs\G
*************************** 1. row ***************************
       Table: privmsgs
Create Table: CREATE TABLE `privmsgs` (
  `msg_id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `root_level` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `author_id` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `icon_id` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `author_ip` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_time` int(11) unsigned NOT NULL DEFAULT '0',
  `enable_bbcode` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_smilies` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_magic_url` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `enable_sig` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `message_subject` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_text` mediumtext COLLATE utf8_bin NOT NULL,
  `message_edit_reason` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_edit_user` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `message_attachment` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `bbcode_bitfield` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',
  `bbcode_uid` varchar(8) COLLATE utf8_bin NOT NULL DEFAULT '',
  `message_edit_time` int(11) unsigned NOT NULL DEFAULT '0',
  `message_edit_count` smallint(4) unsigned NOT NULL DEFAULT '0',
  `to_address` text COLLATE utf8_bin NOT NULL,
  `bcc_address` text COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`msg_id`),
  KEY `author_ip` (`author_ip`),
  KEY `message_time` (`message_time`),
  KEY `author_id` (`author_id`),
  KEY `root_level` (`root_level`)
) ENGINE=InnoDB AUTO_INCREMENT=5238652 DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=COMPACT

I have this modes enabled for the whole session:

mysql> SELECT @@session.sql_mode\G
*************************** 1. row ***************************
@@session.sql_mode: ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,
STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,
ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

When I try to insert something, this happens:

mysql> INSERT INTO privmsgs
    ->   (root_level, author_id, icon_id, author_ip, message_time,
    ->    enable_bbcode, enable_smilies, enable_magic_url, enable_sig,
    ->    message_subject, message_text, message_attachment, bbcode_bitfield,
    ->    bbcode_uid, to_address, bcc_address)
    -> VALUES
    ->   (0, 12345, 0, '127.0.0.0', 123456789, 1, 1, 0, 0, 'test',
    ->    'testing message', 0, '', 'xxx', 'u_12345', '');
ERROR 1364 (HY000): Field 'msg_id' doesn't have a default value

The weirdest thing is that if I create another table running the exact same output of SHOW CREATE TABLE privmsgs that I pasted before (but obviously changing its name to something else, like privmsgs2), I can run the exact same query without any errors or warnings:

mysql> INSERT INTO privmsgs2
    ->   (root_level, author_id, icon_id, author_ip, message_time,
    ->    enable_bbcode, enable_smilies, enable_magic_url, enable_sig,
    ->    message_subject, message_text, message_attachment, bbcode_bitfield,
    ->    bbcode_uid, to_address, bcc_address)
    -> VALUES
    ->   (0, 12345, 0, '127.0.0.0', 123456789, 1, 1, 0, 0, 'test',
    ->    'testing message', 0, '', 'xxx', 'u_12345', '');
Query OK, 1 row affected (0.00 sec)

What is going on?!

Note that disabling STRICT_* modes is not the solution I'm looking for: it's not clean, and the fact that I can run the exact same query on another identical table in the same session suggests (?) that the problem might not be there.

Answer 1

Okay, here are the facts:

• This is the table of a phpBB installation which has been working perfectly for a long time with MySQL Percona.
• When connecting, by default the application sets the STRICT_ALL_TABLES and STRICT_TRANS_TABLES modes, and has been doing that for a long time too.
• Of all the tables the application uses, this is the only one where the described inconsistent behavior appears.
• When creating another table pasting the SHOW CREATE TABLE privmsgs output, the new table didn't show this behavior. When using CREATE TABLE privmsgs2 FROM privmsgs, it did.
• Downgrading to Oracle's MySQL 5.5.31 didn't change any of these facts.

I tried reconstructing the table with ALTER TABLE privmsgs ENGINE=InnoDB, according official documentation, but that didn't help.

So I dumped the table with mysqldump databasename privmsgs > table.sql, changed its name to privmsgs2 in the file with sed and then reimported it with mysql databasename < table.sql. Then I dropped privmsgs and renamed privmsgs2 to privmsgs.

Then it started working perfectly again. I don't understand why and couldn't find any other reference to this behavior. If somebody is able to explain it with a more precise answer than mine, please do it and I'll accept your answer.