是否可以或希望编写异步/事件驱动的SQL Server？

免责声明：这更多的是一个理论问题，而不是一个DBMS问题——这就是为什么我这么说的原因。我可能完全错了，这可能是个坏主意

大量研究表明，任务（线程和进程都有）具有不理想的空间和时间开销，特别是在I/O绑定的应用程序中。根据询问的内容，许多查询实际上可能会受到I/O限制，尤其是在扫描而不是索引命中时。我意识到，这是复杂的，因为并行化查询的愿望似乎相互矛盾。但我不认为这实际上是相互矛盾的。您只需要一个池—大约是NUM_CPU

对于像SQL这样复杂的东西，这可能吗？有可能使用比SQL复杂度更低的东西吗？你可以想象一个线程池（~NUM_CPU）给了作业——一个表示目的和状态的对象——在大海捞针。池中的每个线程都将获得一系列查找内容的作业。当任何线程都在等待I/O时，它可以继续前进，并在给定的不同作业中寻找不同的针。当所有作业“完成”时，排队作业将其汇总

---

。。。或者这是线程的工作——我们只是在userland中重新设计内核线程吗？也许这是真的——正如状态对象复杂性->无限，你只是在重新创造线程。在没有事件的情况下思考它要容易得多，而且我很确定我不知道如何编写基于事件的DB引擎，更不用说基于线程的DB引擎了。这听起来很难，但它是否可能，甚至是可取的呢？

您的问题似乎是：为什么在RDBMS环境中使用异步IO进行磁盘访问

异步IO用于在IO操作运行时不阻塞线程。这样可以减少线程数。这样可以节省堆栈内存和少量操作系统资源。它还可以提高操作系统的调度效率

也就是说，使用异步IO还是线程从磁盘读取并不影响磁盘吞吐量。无论哪种方式，您都将最大化IO子系统。通过改变调用内核的方式，磁盘不会神奇地变得更快。异步IO只改变调用的方式，而不改变调用的功能

---

异步IO通常在高度并发的情况下使用，比如在具有100个甚至数百万个套接字的套接字应用程序中（你不能有1M个线程）。对于磁盘IO，它无助于提高吞吐量，因为您希望应用于磁盘的并行度很小。

这就是为什么我要这么做的原因。但这不是理论问题，而是具体的编程问题。这是实践理论。它属于这个家族的哪个地方？我只是说它不应该在数据库特定的站点上。不确定它是否属于任何SE站点。SE不是用于设计讨论，而是用于发布可以有明确答案的问题。在web服务器和其他各种简单的服务器中存在相似之处。也许有答案。我不明白你为什么在乎。我不明白这怎么会让它更贴近主题。你仍然在试图进行讨论，寻求意见，而不是提出一个客观、正确的问题。不。这不是问题。我想问的是，您是否可以实际地——也就是说，这很难，但有一个优势——摆脱线程，编写一个完全异步的SQL server。您关于磁盘I/O的观点是相关的，但我不确定它是否支持或反对这个想法。请参阅-您可以获得I/O绑定。我只是不确定这是否值得。您将获得更少的上下文切换和更少的开销，但该项目将是疯狂的。想想Nginx和Apache，但要困难得多。是的，实际上你可以做到。这项工作正在进行中。例如，RavenDB在内部是完全异步的。；不要将特定实现（epoll）与异步IO的概念混淆。Linux和Windows都支持异步磁盘IO。；“我只是不确定这是否值得。”这就是我解释权衡的原因。你在寻找一个肯定或否定的答案吗？答案取决于非常具体的情景。不可能笼统地说。；你能简单地解释一下你的问题没有得到回答的地方吗？我是说，使用异步I/O并不意味着应用程序是事件驱动的。只是它在某些有意义的地方使用异步I/O。你是说RavenDB可以在2核机器上用几个线程同时处理100个查询吗？是的。它们基本上从不阻塞IO。使用异步IO和事件驱动通常是一致的。select/poll模型有点过时，不是异步IO的良好基础。在异步IO的现代模型中，您只需为每个IO注册一个回调，就可以神奇地在完成时回调。也许你应该看看boost asio，看看现代的异步IO是什么样子。如果你想知道异步IO是如何变得简单的，那么看看C#async/await。异步代码看起来就像同步代码一样，只是做了一些小的机械更改。RavenDB是用C#写的，肯定会使用wait。