我有一个在 Amazon MySQL/RDS 上运行的应用程序，需要维护 2 周的事务历史记录，之后可以（通常）清除数据。因为这不是一个硬性规则，所以我不能使用按天或按周进行分区来最有效地删除旧数据。
有几个表需要清除，其中许多表具有多个索引和外键约束（父/子）。
我正在删除块中的数据（一次 1000-3000 行）并在每个块之后提交。删除一定数量的块后，清除代码会暂停一段时间。
我的问题是这个过程在 10 到 15 分钟内非常有效，之后我开始看到删除数据块的延迟很大。我相信我的 SQL 尽可能高效。我可以在 MySQL 中的哪个位置更好地了解瓶颈？如果我停止我的代码并等待 15-20 分钟，删除性能会再恢复 10 分钟。
我有一个大的 .sql 文件，其中包含大量 insert into ... values ... 语句。其中许多语句在执行期间会生成警告。如何让 mysql 打印警告？
如果它按下 control-C，则导入停止，我将返回操作系统命令行。
以下是运行 SQL 的示例输出：
Query OK, 9827 rows affected, 5403 warnings (0.20 sec)
Records: 9827 Duplicates: 0 Warnings: 5403
Query OK, 9859 rows affected, 5247 warnings (0.20 sec)
Records: 9859 Duplicates: 0 Warnings: 5247
我也在试图理解为什么 MySQL 认为“加载数据文件”不安全并在混合模式下切换到 RBR，这是否意味着它仅在使用 SBR 时不安全？
我在 MySQL 5.1.52 上运行传统的主/从复制，我的主服务器设置为基于语句的复制。从属上的一些表缺少行（不同的行数），这些表仅使用“加载数据infile ...”在主上插入，具有自动递增的Pks。奇怪的是，从站上丢失的行在行应该在的 PK 值中有间隙。从站被标记为只读，因此没有意外删除。