数据库引擎内部结构

我一直在使用access和mysql ...最近我开始使用linux中的标准文件操作。由于数据库将数据存储在文件中，它们是否对每个sql事务执行文件操作，还是仅对关闭/打开数据库执行文件操作？我认为它更高效地将数据存储在ram中，并使用有效的数据结构来处理更新，并且只写入关闭连接的文件。我现在对关系代数不感兴趣，但是我可以在哪里找到更多的细节来回答我的问题？数据库引擎内部结构

来源

2012-01-01 dasman

只是出于好奇，如果数据库加载/保存在打开/关闭，你会怎么想象多个用户/连接方案的工作？这显然是一个相当复杂的问题。通过查看他们的（公开可用的）源代码，查看像mysql或postgresql这样的数据库如何在内部工作可能是有价值的。 – 2012-01-01 06:41:33

这比文件系统和RAM讨论要复杂得多。 MS SQL Server具有完备的数据存储方法（我确信MySQL也是如此，不确定Access是什么）。我将从我的MS SQL Server的经验中回答。

这里是先从一篇文章：http://msdn.microsoft.com/en-us/library/ms189051.aspx

为了让在你的问题一点见解：

我认为它更有效地在RAM中的数据存储与高效的数据结构来处理更新，并且只写入文件关闭连接。

数据库引擎的绝对使用RAM来提高性能，特别是对于读（包括索引）。通常（并非总是）读取次数大于写入次数，即使在OLTP环境中也是如此。读数据实际上比写数据要昂贵得多;然而，写入数据带来了可能产生重大影响的锁定的惩罚。
实际的缓冲实现将因数据库而异，也可能取决于是否正在使用某个事务来写入数据。有些东西是数据库引擎必须考虑的，例如如果另一个调用者请求脏读取会怎样？或者如果系统在操作过程中失败会怎么样？如果数据库服务器是集群或复制的呢？这并不意味着这是不可能的，只是这是一个复杂的问题。
完整性保证的一个示例：在MS SQL Server镜像环境中，可以使用作为证明者的第三台服务器写入两台服务器。写操作可以是异步的，也可以是写操作同步，双方都需要继续进行写操作。这比较慢，但可以保证（在合理范围内）数据实际上已发送到两个节点，并且两个节点都确信其持久性操作成功。
由于开幕式和闭幕式都相当昂贵，连接通常会集中在一起而不是真正关闭。连接可以（并且通常应该）被主动重用（不管是否合并）。

我发现这篇文章在MS SQL Server缓冲区写入有趣：http://msdn.microsoft.com/en-us/library/aa337525.aspx。

它可能会更具体地回答有关数据写入磁盘时的问题。

来源

2012-01-01 06:26:01

为了保持完整性，写入操作需要在每个事务完成后完成。
交易完成后，执行COMMIT语句。
在单个事务中可能有很多语句（SELECT，INSERT，UPDATE & DELETE）。
仅在打开和关闭时写入将无法为ACID事务提供足够的支持。

许多数据库维护一个单独的内部日志，目的是记录事务，对日志的写入是关键操作，并且日志可用于在崩溃恢复情况下重建数据库。

只要日志已成功写入磁盘，某些数据库实现可能会选择将实际实体数据在稍后的时间保存到磁盘。
如果在将实体数据写入磁盘之前发生崩溃，则可以从内存中的缓冲区中检索相同数据的后续读取，恢复过程可以在下次启动时应用来自日志的更改，从而允许数据库保持内部一致性。

来源

2012-01-01 07:18:02 crowne

+1 - 用于说明日志在事务数据库中的重要性。 – 2012-01-01 07:26:38

数据库引擎内部结构

回答

相关问题