InnoDB的交易：锁等待超时

Question

我有我的数据库中的表（实际上是几个相关的表），即得到可以手动从不同的点，通过我们的界面操作也自动地从两个来源在连续的基础。定期更新可能包含大量数据，并可能导致数千次插入/更新。为了提高我已经使用了插入/更新的性能“SET自动提交= 0”从周围这些自动化源的更新。这导致了期望的性能改进，甚至可能超出预期。但是现在的问题是，如果自动来源重叠，或者如果进行手动更新非常频繁的数据库锁起来，过了一会儿抛出一个错误：

锁等待超时超标;请尝试重新启动交易

这甚至在自动提交，而且没有交易一个单独的语句被抛出，但我想这是合理的，以及它是否与交易相冲突。我已阅读了各种建议，但不幸的是没有理想的解决方案。我想我的选择是：

1. 尝试订购更新/上，这样的要求在同一个数量级上的所有线程锁并没有僵局的表插入。不幸的是，这是不可能的，更新需要按照他们收到的顺序应用。

2. 使用LOCK TABLES系列化事务。这在理论上是可能的，但一）除了来自两个自动源的表从系统中的多个点，包括触发器，时间表，手动地从各种接口更新。这将是一场噩梦，以确定并保持围绕这些地方LOCK TABLES，没有简单的方法来知道所有已经确定，和b）LOCK TABLES已锁定涉及的所有表和更新/插入虽然不经常，但有时可能需要更新多个表的更新的结果，需要再次确认和维护，使它们都包含在LOCK TABLES可能被更新的所有表。

3. 在每次更新之前使用信号量表，以便像上面的LOCK TABLES一样实现更新的序列化，但实际上并不需要使用LOCK TABLES。这是一个改进，但仍然存在以上问题a）的LOCK TABLES。

其他建议？可以自动提交的改善效益= 0（交易）来实现，不涉及锁定一些其他的方式？可以将innodb配置为实际上不锁定或锁定更新/插入更少？

不得已的选择可能会移动到MyISAM表。这实际上是否会通过大量的插入/更新操作实现性能改进？

谢谢

Answer 1

可以实现自动提交= 0，而仍没有使用长事务的好处。

a）你可以提交事务每隔X语句，假设你不需要回滚整个交易

B）而不是使用自动提交= 0，你可以在导入前/后使用ALTER TABLE x DISABLE keys/ALTER TABLE x ENABLE keys 。这是操作的性能提高的原因 - 不更新的非唯一索引，直到交易完成后，再批量更新。