MariaDB：在分区表上发生隐式提交

我有两张桌子：主桌和副桌。两者都是InnoDB表

第一个分区是按范围分区的，当前只有一个分区

| main | CREATE TABLE `main` (
  `main_id` int(10) NOT NULL AUTO_INCREMENT,
  `type` varchar(64) DEFAULT NULL,
  `username` varchar(64) DEFAULT NULL,
  `file_name` varchar(256) DEFAULT NULL,
  `the_date` datetime DEFAULT NULL,
  `partition_key` int(6) unsigned DEFAULT NULL,
  `content` mediumblob,
  `completed_date` datetime DEFAULT NULL,
  `info` varchar(255) DEFAULT NULL,
  KEY `pk_main` (`main_id`),
  KEY `idx_main_types` (`type`)
) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (partition_key)
(PARTITION main_201807 VALUES LESS THAN (201808) ENGINE = InnoDB) */ |

辅助表未分区

| secondary | CREATE TABLE `secondary` (
  `sec_id` int(10) unsigned NOT NULL,
  `username` varchar(64) NOT NULL,
  `file_name_hash_md5` varchar(32) NOT NULL,
  `file_content_hash_md5` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`sec_id`),
  UNIQUE KEY `unq_secondary_file_name` (`file_name_hash_md5`,`username`),
  UNIQUE KEY `unq_secondary_file_content` (`file_content_hash_md5`,`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

我运行的代码在事务内部工作。事务隔离已读\已提交，自动\已提交为false。代码将一条记录插入到main，然后将一条记录插入到secondary，如果一切正常，则提交

但在我的场景中，由于唯一约束冲突，第二次插入失败。在我的代码中，我在事务提交/回滚之前捕获相应的异常，并将该事务标记为回滚。我可以在调试器中看到实际调用了Connectionrollback。我还在MariaDB中启用了查询日志，在设置之后，我在这个连接中只看到3个查询：两个插入和一个回滚

---

但是在回滚之后，插入到主表中的记录仍然存在，并且不会回滚。此外，如果我在提交或回滚之前捕获代码中的断点，但在执行两个插入之后，一个成功，另一个失败，那么我可以从不同的mysql客户端会话中看到主记录，即使它还不应该提交

我知道在同一个会话中发出TRUNCATE之类的操作可能会导致隐式提交，但我在日志中只有两个插入和一个回滚

为什么会发生这种情况？是否有任何工具允许跟踪此类隐式提交或提交数据的原因

MariaDB版本为10.0.34-MariaDB-0ubuntu0.16.04.1

更新

---

在版本为10.0.30-MariaDB-1~jessie的MariaDB中，它工作正常，因此问题似乎在于特定版本10.0.34或特定于Ubuntu的补丁。

除非您可以使用mysql CLI重现此行为，我怀疑您的应用程序逻辑有问题。插入到主表中的记录保留在那里，不会回滚-您有什么证据？如果您处于同一连接中，但尚未提交/回滚，那么这可能是正确的。@我只是在mysql客户端的另一个会话中使用select*from main进行检查。我在回滚发布之前和发布之后都这样做了，在这两种情况下，我都可以看到刚刚插入的主记录。在10.0.30-MariaDB-1~jessie版本的MariaDB中，它工作正常，所以问题似乎是特定的10.0.34版本或Ubuntu特定的补丁。