在过去的4天里，我的夜间更新出现了大量问题，除了1晚之外，这4天之间一切都很顺利。
在这些更新期间，我更新了几个全文索引。我是这样做的。
- 删除全文索引
- 更新全文表
- 添加全文索引
这已经超过2年完美。通常的更新时间约为3-4小时，这对于每晚更新的数据量是正常的。但自周五以来，更新时间确实在9-12小时之间！
昨晚服务器故意被引擎崩溃，这是在错误日志中
InnoDB：警告：一个长信号量等待： - 线程8676已经在dict0boot.ic第36行等待241.00秒信号量：Mutex在0000000053B0C1E8创建文件dict0dict.cc第887行，lock var 1 waiters flag 1 InnoDB：#### ##启动InnoDB Monitor 30秒打印诊断信息：InnoDB：待处理的preads 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：如果你重复断言失败或崩溃，即使是InnoDB：在mysqld启动之后，可能会有InnoDB：InnoDB表空间中的损坏。请参考InnoDB：http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB：关于强制恢复。
我刚刚重新启动服务器，它很好，所以我现在等待在bugs.mysql.com发布完整的错误报告
我在这个page上发现了一些东西，它似乎是同一类问题，但没有进一步的消息。
我不知道从哪里开始，我不知道为什么会突然发生这种情况。
我必须从这里提供什么样的细节？
编辑
在阅读this后，它说明了这一点
“MySQL 5.6及更高版本中的体系结构更改使得更多工作负载适合于禁用自适应哈希索引，而不是早期版本，尽管默认情况下仍然启用它。”
我已经使用SET GLOBAL innodb_adaptive_hash_index=0禁用了自适应哈希索引，我现在正在尝试第一次尝试查看问题是否已修复。情况就像晚上一样。
夜间更新：
更新很顺利。不到6个小时。全文索引更新没有问题，但我仍然发现使用JOIN的简单更新查询很慢。 （在8秒中有40000条记录，通常在低于1时完成）。
将继续今天尝试和微调它。
问题出在innodb_adaptive_hash_index
innodb_adaptive_hash_index=0和重启解决了这个问题。
正如我在问题中所述
“MySQL 5.6及更高版本中的体系结构更改使得更多工作负载适合于禁用自适应哈希索引，而不是早期版本，尽管默认情况下仍然启用它。”
这对我有用，因为我没有再次遇到同样的问题。
也有这样的问题。数据库每天都无缘无故地破坏了几次。我不确定这是否对我有帮助，但我的解决方案是优化所有表格。到目前为止三天，这个问题不再出现了。
有很多方法可以优化所有表，但我将举例说明如何使用PHP通过Linux控制台执行此操作
#!/bin/php -n
<?php
// /bin/php -n /sysmyx/mysql/hand_optimize_all_tables.php
dl('mysqlnd.so');
dl('mysqli.so');
$timestart = time();
$n=0;
$con=mysqli_connect("localhost","roootmysql","passss");
if (mysqli_connect_errno()) { echo "mysql error".PHP_EOL;
exit;
}
mysqli_query($con,"SET GLOBAL innodb_buffer_pool_dump_now = 1");
$res = mysqli_query($con,"SHOW DATABASES");
while ($row = mysqli_fetch_assoc($res)) {
$db_name=$row['Database'];
if ($db_name!="mysql" && $db_name!="information_schema" && $db_name!="performance_schema" && $db_name!="" && $db_name!="sys") {
echo '*'.$db_name.'*'.PHP_EOL;
//!!!!!!!!!!!!!!!!!!!!!!!// $query="SHOW TABLE STATUS FROM $db_name where Data_free>0;";
$query="SHOW TABLE STATUS FROM $db_name";
$tabbll=mysqli_query($con,$query);
while ($row2 = mysqli_fetch_assoc($tabbll)) {
$n++;
$opt_table='`'.$db_name.'`.`'.$row2['Name'].'`';
$query2="OPTIMIZE TABLE $opt_table";
$time1 = time();
mysqli_query($con,$query2);
$time2 = time();
$time3 = $time2-$time1;
echo $n.' '.$time3.' '.$row2['Data_free'].' '.$opt_table.PHP_EOL;
}}}
mysqli_query($con,"SET GLOBAL innodb_buffer_pool_load_now = 1");
mysqli_close($con);
$timeend = time();
$time = $timeend-$timestart;
?>
也是my.cnf设置的一部分
innodb_thread_concurrency=0
flush_time=0
innodb_adaptive_hash_index=0
innodb_adaptive_hash_index_parts=1
innodb_purge_threads=1
innodb_fatal_semaphore_wait_threshold=60
更新17-07-2019
我发现问题导致了我这个错误。
问题是我有一个4,000行的表。该表每秒收到大约1000次更新。此外，同时从该表中，每秒约有500个选项。通常，选择时间为0.006秒，但几天后选择时间变为5秒。在那之后，成千上万的选择被聚集在队列中并且有一个错误的时刻“长信号量等待”。
可能的解决方案：
1）创建另一个表结构，检查索引，将表拆分为几个表。
2）每隔几个小时优化一次表。
3）使用此表的缓存系统
可能的搜索问题：
一个有用的脚本，可以帮助您查看在mysql崩溃时收集的查询。通过cron每分钟运行一次脚本。
#!/bin/bash
USER=$(</sys_snting/mysql_user)
PASSWORD=$(</sys_snting/mysql_pass)
num=$(mysql --user=$USER --password=$PASSWORD -s -N -e "SELECT count(*) FROM information_schema.processlist ;")
if [ $num -ge 500 ] ; then
mysql --user=$USER --password=$PASSWORD -e "show full processlist" > /media/bug/$(date +%Y%m%d%H%M%S)_$num.txt
echo $num
# Kill selections that can lead to "A long semaphore wait"
# mysql --user=$USER --password=$PASSWORD -N -e "SELECT Id FROM information_schema.processlist where INFO like '%SELECT \`d_narfe\` FROM \`maitableep_com\`.\`5000_active\` WHERE%';" | while IFS= read -r loop
# do
# echo "$loop"
# mysqladmin --user=$USER --password=$PASSWORD kill $loop
# done
fi