mysql - 在执行mysqlcheck时Innodb表已损坏，但mysql服务器现在或重新启动时不会崩溃

Question

我有一个数据库，其中有InnoDB表，其中一个InnoDB表被标记为已损坏（我知道数据丢失等）。但是，当我重新启动MySQL时，它不会崩溃。
我原以为它会崩溃，但事实并非如此。（我之前读过，如果innodb table损坏，mysql server就会停止）
现在不应该崩溃吗？
innodb是我的默认数据库引擎。

Answer 1

损坏的表不一定会导致崩溃。不过，您应该修复表，如果可能的话，从备份中重新加载表。对损坏表的操作充其量是不可靠的，而且无论如何，它不会像您已经发现的那样，不给您正确的结果。
不要相信系统没有“爆炸”这个事实——一个数据库有几个中间状态。你现在所处的位置很可能是“我还没有爆炸，我在等待腐败蔓延并污染其他表的数据”。如果你知道桌子坏了，现在就行动。
关于修复InnoDB表，请参见How do I repair an InnoDB table?。
要验证InnoDB表是否损坏，请参见https://dba.stackexchange.com/questions/6191/how-do-you-identify-innodb-table-corruption。
侦查腐败
要做到这一点，你需要一个验收测试，它将检查一堆数据，并给它一个干净的健康账单——或者不。将表导出到SQL并查看是否可能，和/或对元组基数和/或关系和。。。你明白我的意思。
在一个不需要任何人写入的表上，因此任何修改都等于损坏，磁盘文件的MD5可能更快。
为了提高效率（例如在生产系统中），您可以考虑文件快照、数据库复制，甚至高可用性。这些方法将检测程序损坏（例如，恶意更新），但可能检测不到主设备上的某些硬件损坏（给出假阴性：从设备上的检查已完成，并且主设备上的数据仍然损坏），或者可能在从设备上遭受灾难（失败并引发假阳性，因为主设备上的数据实际上是没有污渍的）。
重要的是（而且有效的）监控系统生命统计数据，既要捕捉即将发生的故障的第一个症状（例如，使用SMART），又要为法医调查提供数据（“有趣的是，每次数据库出现故障时，总是在系统负载突然达到峰值之后不久——如果我们找出了导致这种情况的原因，会怎么样？”）.
当然，还要依赖完整和足够的备份（并不时地运行测试还原）。在那里，做了那件事，把我的屁股交给我）。
腐败原因[与原问题无关]
损坏源因软件设置而异。当然，总的来说，一定有什么东西侵入了server memory representation-writer process-OS handle-journaling-IOSS-OS cache-disk-disk cache-internal file layout链并造成了严重的破坏。
不正确的系统关闭可能会在多个级别造成混乱，从而阻止在管道的任何阶段写入数据。
处理磁盘上的文件会弄乱最后一个阶段（使用自己的管道，服务器对此一无所知）。
其他更多的可能存在：
硬盘本身存在细微的固件/硬件故障，
由于磁盘磨损或固件损坏，甚至固件更新有缺陷（我似乎记得几年前的日立声学管理更新，可以在稍有不同的型号上运行），可能是意外的，也可能是不可恢复的。更新后，磁盘“思想”比实际拥有更多的缓存，并且写入缓存的不存在区域，直接进入比特天堂。
“有意”而且可能是可恢复的：有时使用hdparm可能会使硬盘过薄。如果每个组件都适合这种级别的性能，并且知道它，或者至少能够在不适合的情况下发出信号，那么将磁盘设置为最高性能是非常好的。有时你得到的所有“警告”都是系统故障。
进程空间或IOSS损坏：在一个Apache安装中看到了这一点，可能是由于一个suid root的CGI，access.log文件中填充了一个GIF图像流，该图像流应该进入用户的浏览器。修正后什么也没发生，但如果它是一个更重要的文件而不是一个日志。。。？这些问题可能很难诊断，您可能需要检查所有日志文件，以查看是否有应用程序注意到或做了任何不好的事情。
硬盘扇区重定位：传说中的发生，从未见过它自己，但现代硬盘有“备用”扇区，他们将交换有缺陷的扇区，以保持“零缺陷”表面。但是，如果缺陷扇区碰巧不再可读并且被替换为空扇区，则净效果与该扇区突然被归零相同。您可以使用智能报告（hddhealth或smartctl）轻松检查。
当然，还有更多其他可能性存在，这取决于设置。googleforfilecorruption可以找到一个jillion页面；可以添加到查询中的有用术语有文件系统（ext4、NTFS、brtfs，…）、硬盘品牌和型号、操作系统、遇到问题的软件、安装的其他软件。