在过去的4天里，我的 夜间更新 遇到了很多问题，除了1天晚上，在这4天之间一切都还好。

在这些更新期间，我更新了几个全文索引。我以这种方式做。

1. 删除全文索引
2. 更新全文表
3. 添加全文索引
   

这已经 完美地工作了2年多了 。通常的更新时间约为3-4小时，这对于每晚更新的数据量来说是正常的。但是实际上，自星期五以来，更新时间一直在
9 到 12个 小时之间！

昨晚服务器因引擎故意崩溃，这在错误日志中

InnoDB：警告：长时间等待信号量：-线程8676在dict0boot.ic行36上等待了241.00秒信号量：互斥体在0000000053B0C1E8创建了文件dict0dict.cc行887，锁定了var
1 waiters标志1 InnoDB： ##启动InnoDB Monitor 30秒以打印诊断信息：InnoDB：待处理前导0，pwrites 0

InnoDB：######诊断信息打印到标准错误流InnoDB：错误：信号灯等待持续了600秒以上InnoDB：我们故意使服务器崩溃，因为它似乎已挂起。2014-07-21
05:20:54 1384 InnoDB：文件srv0srv.cc行1748中的线程4996断言失败

InnoDB：我们有意生成一个内存陷阱。InnoDB：向http://bugs.mysql.com提交详细的错误报告。InnoDB：如果您反复声明失败或崩溃，甚至在mysqld启动后立即出现InnoDB：，则InnoDB表空间中可能存在InnoDB：损坏。请参考InnoDB：http : //dev.mysql.com/doc/refman/5.6/en/forcing-innodb-
recovery.html InnoDB：关于强制恢复。

香港专业教育学院刚刚重新启动服务器，它运行正常，所以现在我正在等待在bugs.mysql.com中发布完整的错误报告

我在此页面上发现了一些东西，这似乎是同样的问题，但是没有进一步的消息。

我不知道从这里去哪里，我也不知道为什么这突然发生。

我必须从这里提供什么样的详细信息？

• MySQL服务器版本：5.6.13
• sort_buffer_size = 2M
• innodb_buffer_pool_size = 53G
• innodb_log_buffer_size = 4M
• innodb_flush_log_at_trx_commit = 0
• innodb_log_file_size = 25G

编辑

阅读此内容后，它指出

“与早期版本相比，MySQL 5.6及更高版本中的体系结构更改使更多的工作负载适合于禁用自适应哈希索引，尽管默认情况下仍启用该功能。”

我已禁用了使用的自适应哈希索引 SET GLOBAL innodb_adaptive_hash_index=0
，现在尝试进行第一次尝试以查看问题是否已解决。情况就像晚上。

夜间更新：

更新进行得很好。少于6小时。全文索引更新没有问题，但是我仍然发现使用进行简单的更新查询JOIN很慢。（以8秒为单位的40000条记录，通常少于1）。

今天将继续尝试并对其进行微调。