我对数据库缺乏经验,刚刚阅读了 "n+1 selects issue" .我的后续问题:假设数据库与我的程序驻留在同一台机器上,缓存在 RAM 中并正确索引,为什么 n+1 查询模式很慢?
作为一个例子,让我们从接受的答案中获取代码:
SELECT * FROM Cars;
/* for each car */
SELECT * FROM Wheel WHERE CarId = ?
用我对数据库缓存的心智模型,每个
SELECT * FROM Wheel WHERE CarId = ?
查询应该需要:get()
)CarId
的 k 个轮子的列表(另一个哈希图 get()
)即使由于内部存储器结构的原因,我们将其乘以一个小的常数因子以获得额外的开销,它仍然应该非常快。进程间通信是瓶颈吗?
编辑 :我刚刚通过 Hacker News 找到了这篇相关文章:Following a Select Statement Through Postgres Internals. - HN discussion thread .
编辑 2 :为了澄清,我确实假设
N
要大。一个不平凡的开销会增加一个明显的延迟,是的。我首先要问的是,对于上述设置,为什么开销并不小。
最佳答案
您是正确的,在您描述的场景中避免 n+1 选择不太重要。如果数据库在远程机器上,> 1ms 的通信延迟很常见,即 cpu 将花费数百万个时钟周期等待网络。
如果我们在同一台机器上,通信延迟要小几个数量级,但与另一个进程的同步通信必然涉及上下文切换,通常花费> 0.01 ms(source),即数万个时钟周期.
此外,ORM 工具和数据库每个查询都会有一些开销。
总而言之,如果数据库是本地的,避免 n+1 次选择的重要性要小得多,但如果 n 很大,则仍然很重要。
关于sql - 为什么 n+1 选择模式很慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26245404/