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

我有一个数据库，其中包含InnoDB表，其中一个InnoDB表被标记为已损坏（我知道数据丢失，等等）。然而，当我重新启动MySQL时，它并没有崩溃

我以为它会崩溃，但它没有。（我之前读过，如果innodb表损坏，mysql服务器将停止）

它现在不应该崩溃吗

---

innodb是我的默认数据库引擎。

损坏的表不一定会导致崩溃。您应该修复该表，如果可能的话，从备份中重新加载该表。对损坏的表的操作充其量是脆弱的，而且无论如何，正如您已经发现的那样，它不会给出正确的结果

不要相信系统没有“爆炸”——一个数据库有几个中间状态。您现在所处的位置很可能是“我还没有爆炸，我正在等待腐败蔓延并污染其他表的数据”。如果您知道该表已损坏，请立即采取行动

关于修复InnoDB表，请参阅

要验证InnoDB表是否已损坏，请参阅

侦查腐败 要做到这一点，您需要一个验收测试，该测试将检查一组数据，并为其提供一份干净的健康清单——或者不检查。将表导出到SQL并查看是否可行，和/或对元组基数和/或关系运行检查，以及。。。你明白我的意思。 在一个不希望有人写入的表上，任何修改都会导致损坏，因此磁盘文件的MD5可能会更快

为了提高效率（例如在生产系统中），您可以考虑文件快照、数据库复制，甚至高可用性。这些方法将检测程序损坏（例如恶意更新），但可能检测不到主设备上的某些类型的硬件损坏（给出假阴性：从设备上的检查结果，并且主设备上的数据仍然损坏），或者从设备中可能发生故障（由于母版上的数据实际上未被污染，因此失败并产生假阳性）

监控系统生命统计数据非常重要（且非常有效），既可以捕捉即将发生的故障的第一个症状（例如，使用SMART），也可以为法医调查提供数据（“有趣的是，每次DB发生故障时，总是在系统负载突然达到峰值后不久发生——如果我们找出原因会怎样？”）

当然，我还需要依靠完整和充分的备份（并时不时地运行一次测试还原。在那里，我做到了，把我的屁股交给了我）

腐败原因[与原始问题无关] 损坏源因软件设置而异。通常情况下，服务器内存表示编写器进程操作系统句柄日志丢失操作系统缓存磁盘缓存内部文件布局链中肯定有东西侵入，并造成严重破坏

不当的系统关闭可能会在多个级别造成混乱，从而阻止在管道的任何阶段写入数据

人工处理磁盘上的文件会弄乱最后一个阶段（使用自己的管道，服务器对此一无所知）

还有其他更深奥的可能性：

• 硬盘本身存在细微的固件/硬件故障，
  • 由于磁盘磨损或固件缺陷，甚至固件更新缺陷（我似乎记得几年前，日立针对声学管理的更新可能会针对稍微不同的型号运行。更新后，磁盘“思考”它拥有比实际更多的缓存，并且写入缓存中不存在的区域（当然，直接写入到比特天堂）
  • “有意”且可能可恢复：有时可能会使用

    hdparm

    将硬盘拉伸得太薄。如果每个组件都适合该级别的性能，并且知道该级别的性能，或者至少能够发出信号（如果不适合），则将硬盘设置为最高性能是非常好的。有时所有的“警告”你得到的是一个系统故障
• 进程空间或IOSS损坏：在Apache安装中看到了这一点，可能是由于suid root的CGI，access.log文件中填充了一个应该发送到用户浏览器的GIF图像流。修复了此问题，但什么也没有发生，但是如果它是一个更重要的文件而不是日志…？这样的问题可能很难诊断，您可能需要检查所有日志文件，以查看某个应用程序是否注意到或执行了任何异常操作
• 硬盘扇区重新定位：传说中会发生，我自己从未见过，但现代硬盘有“备用”扇区，它们将用有缺陷的扇区替换，以保持“零缺陷”表面。除此之外，如果有缺陷的扇区恰好不再可读，并被替换为空扇区，净效果与该扇区突然归零的效果相同。您可以使用智能报告（

  hddhealth

  或

  smartctl

  ）轻松检查这一点

---

当然，根据设置的不同，还存在许多其他的可能性。通过谷歌搜索文件损坏会发现大量页面；可添加到查询中的有用术语有文件系统（ext4、NTFS、brtfs等）、硬盘品牌和型号、操作系统、遇到问题的软件、安装的其他软件。

您有什么具体问题吗？“这可以吗？”“如何使表在mysqlcheck中不作为损坏返回？“还是别的什么？我预计它会崩溃，我的问题是为什么mysql服务器没有崩溃，而innodb表被标记为损坏？我需要知道的是，是否有任何其他机制可以发现这种损坏？如果我在生产中有一个数据库，我想监控它以尽早检测损坏，我应该怎么做？（根据我的经验，尽管表已损坏，但mysql服务器运行良好）如果我有一个守护进程运行以监视