如何将写和读分开，以最小化繁重读查询的影响？

Question

我的数据库中有大量写操作的表。需要由其他人运行只读查询。我不知道他们查询的复杂性和数量，但我知道他们什么时候开始这样做，写的东西就会变得超流。因此，将写操作与读操作分开似乎是可行的。

复制是答案吗？我还可以试试别的吗？

Answer 1

因为任何与性能相关的事情都是“视情况而定”。

一般来说，你忽略了这一点，因为一般来说，隔离级别会为你解决这类问题。你可以看看书，看看它是如何工作的。一般来说，如果你不清楚自己在做什么，那么干涉它是不明智的。

如果您结束处理有关它的问题，您可以：

1)复制(但您需要深入研究有关它的细节)。优点是简单，缺点是浪费服务器、磁盘和cpu。

2)创建stag表。这是一种简单的解决方案，适用于在繁重的读取表上进行大量重写的情况。举例说明。您有一个are服务，其中用户有时会上传大型csv文件，而这些数据会散布在stag表中。这个简单的无索引表充当了原始数据的缓冲区(或队列)。稍后，在“机会窗口”中，该数据被插入到真实的表中。需要对上传的数据进行非readly查询。它的优点是很容易处理不好的格式化数据，只让清理过的数据进入你的数据库。也很容易实现，例如，您可以在每日完整备份之后或之前创建一个SQL服务到它。

3)通过查询优化隔离级别的查询:优点是如果你真的知道该怎么做系统，缺点是:很难做正确的时间，容易让你的系统在死锁，幽灵和脏读取和丢失数据的地狱。还需要大量的时间来以正确的方式实现和维护(您必须密切关注已调优的查询以确保)。

编辑关于的评论:真的吗？它从SQL2000开始就被弃用了！这是懒人的灵丹妙药，但效果不佳。考虑这样一种场景:您进行了一次脏读，处理了一些数据，并持久存储了更多与该脏读相关的数据。现在使用回滚来撤消脏的回滚，你现在得到了一个孤立的行，或者更糟糕的数据完整性地狱。除非您仍在使用SQL Server 7，否则不要再使用它。研究隔离级别，以了解NOLOCK变得多么糟糕和无用(在过去15年中！)

Answer 2

对我来说，正确的答案是复制，你可以有一个快照复制，在你的插入数据库中有一组不同的索引，在你的读取数据库中有另一组索引。一个专注于快速插入，另一个专注于快速搜索。