为什么“大”文本文件中的数据会损坏 - 使用数据库的原因

Question

我刚刚开始学习数据库和使用 mysql。我读到数据库比拥有大的 ascii 文本文件更可靠，并且随着 ascii 文本文件变大，它们更容易损坏。

有人可以解释为什么会出现这种情况以及数据库如何在高层次上防止这种情况吗？谢谢你。

Answer 1

恐怕我只能与 MS SQL Server 交谈，而不是与 MySQL 交谈。SQL Server 将大型数据库分解为PAGES大小为 8k 的小块。这里有几个优点。任何时候都可以使用大文本文件重写整个文件。对于 SQL Server，当您进行更改时，您只需记下PAGES已更改的内容。这意味着您不是在写入兆字节、千兆字节甚至 TB 字节，而是以 8K 块的形式记录信息。更少的写入意味着更少的导致损坏的机会。

那么一旦你有一些腐败会发生什么？那么在文本文件中，您不会意识到损坏的存在，直到您碰巧查看文件的损坏部分或文件将不再打开。这意味着随着时间的推移，越来越多的腐败会随着时间的推移而建立。在 SQL Server 中，每个页面都有一个CHECKSUM内置的。这CHECKSUM是在几个条件下检查的。每次写入该页面时，何时使用该WITH CHECKSUM选项进行备份以及何时DBCC CHECKDB运行。作为旁注，DBCC CHECKDB检查许多不同的损坏可能性，而不仅仅是CHECKSUM. 因此，如果您（或您的 DBA）小心，他们会更快地发现损坏。

这导致我们修复腐败。在文本文件中，如果您的网络管理员正在进行适当的备份，那么您有望将文件恢复到损坏之前。如果你足够早地发现腐败。如果没有，可能没有足够旧的备份。此外，您唯一的选择是恢复整个文件。这意味着自损坏发生以来对您的文件所做的任何更改都将丢失。数据库提供了多种恢复方法。如果您进行定期备份，您当然可以只恢复数据库。这与您的文本文件没有太大区别。但是，至少在 SQL Server 中，还有一些选项可以将数据库的某些部分还原到PAGE等级。事实上，对于某些类型的高可用性，甚至可以选择在发生损坏时立即自动修复页面。

这里有一些额外的阅读给你。

页面校验和上的 SQL 技能帖子。

了解页面和范围

DBCC CHECKDB 和数据库完整性

抱歉，这是 MS SQL Server 而不是 MySQL，但我想有些原理是相同的或至少非常相似。