简短版本：
INSERT INTO SELECT到具有全文索引的表中，相同的数据有时需要25秒，有时需要2500秒。我们不知道这个巨大的差距来自哪里。
长版：
我遇到了一个cronjob问题，它将新数据导入导入表，并通过INSERT INTO SELECT语句将此数据复制到生产表。由于使用mysql全文索引进行更新所花费的时间，我已经拆分了表 - 使用一个INSERT INTO SELECT将数据插入到此表中似乎比使用许多单个插入语句更快
导入新数据的cron每5分钟运行一次。有一个函数可以检查cron的实例是否正在运行以禁止并行运行脚本。通常每个cron调用大约有500条新记录。 在凌晨1-2点的夜晚，有更多的新数据（大约5.000 - 15.000个新记录），而且cron的运行时间超过5分钟。
当cron在夜间运行很长时间并且在跟踪这些查询的性能时，我检测到INSERT INTO SELECT语句的性能非常（！）慢。要复制大约15.000条新记录（文件大小约为30 MB），查询需要超过2.500秒！
查询是：
INSERT IGNORE INTO mentiondata
SELECT * FROM mentionimport
WHERE id <= 1203780;
我对查询进行了分析，结果如下：
2012-10-31 06:52:06 Queryprofile: {
"starting":"0.000036",
"checking permissions":"0.000003",
"Opening tables":"0.000132",
"System lock":"0.000003",
"Table lock":"0.000007",
"init":"0.000041",
"optimizing":"0.000007",
"statistics":"0.000023",
"preparing":"0.000005",
"executing":"0.000002",
"Sending data":"999.999999",
"end":"0.000017",
"query end":"0.000005",
"freeing items":"1.458159",
"logging slow query":"0.000050",
"cleaning up":"0.000007"}
在进程列表中，发送数据超过2.500 - 在配置文件中它只有999.999999。也许这是profiler-limit - 无论如何......
真正奇怪的是：当我尝试通过删除fulltext-table中的记录来重现问题（DELETE FROM prompdata WHERE id＆gt; = 1203780;）并手动启动复制过程时，它只需要大约25秒！ !!
所以我没有得到它，我真的需要帮助！我不明白为什么同一个查询之间存在这样的性能差异！我在运行cron-copy-statement时检查了mysql-processlist - 没有其他查询锁定表或其他东西。进程列表中只有单个复制查询 - 并且“发送数据”超过2.500秒。没有其他任何影响服务器运行性能的cron或任何其他任务。似乎mysql-server每晚都会变慢，或者在插入语句发生之前很久就打开连接时sql-query需要很长的时间（将数据插入到副本导入表中）。 p>
是否有任何状态变量我可以检查为什么mysql这么慢？有可能检查为什么这些查询这么慢？这里有一些服务器变量信息：
bulk_insert_buffer_size: 268435456
key_buffer_size: 536870912
query_cache_size: 536870912
感谢您的帮助！
蒂莫