对于具有
nmUpdatedeleteCreate我一般来说的是mysql和sqlite。
由于您无法控制所选的算法，因此无法直接知道。但是，如果没有索引，SELECT 的复杂度应该是 O(n)（表扫描必须检查每条记录，这意味着它将随着表的大小而缩放）。
使用索引，SELECT 可能是 O(log(n))（尽管这取决于用于索引的算法和数据本身的属性（如果这对于任何实际表都适用））。要确定任何表或查询的结果，您必须求助于分析真实世界的数据才能确定。
没有索引的 INSERT 应该非常快（接近 O(1)），而 UPDATE 需要首先找到记录，因此会比到达那里的 SELECT 慢（稍微）。
当索引树需要重新平衡时，带有索引的 INSERT 可能会再次处于 O(log(n)^2) 的范围内，否则更接近 O(log(n)) 。如果 UPDATE 影响索引行，那么除了 SELECT 成本之外，还会出现同样的速度减慢。
编辑： O(log(n^2)) = O(2log(n)) = O(log(n)) 您的意思是 O(log(n)^2) 吗？
一旦您谈论混合中的 JOIN，所有的赌注都消失了：您将必须分析并使用数据库查询估计工具来了解它。另请注意，如果此查询对性能至关重要，您应该不时重新分析，因为查询优化器使用的算法会随着数据负载的变化而变化。
另一件事要记住...big-O 不会告诉您每笔交易的固定成本。对于较小的桌子，这些可能高于实际的工作成本。举个例子：跨网络查询单行的设置、拆卸和通信成本肯定会比在小表中查找索引记录要多。
因此，我发现能够在一个批次中捆绑一组相关查询对性能的影响比我对数据库本身所做的任何优化都要大得多。
我认为真正的答案只能根据具体情况（数据库引擎、表设计、索引等）来确定。
但是，如果您是 MS SQL Server 用户，您可以熟悉查询分析器 (2000) 或 Management Studio (2005+) 中的估计执行计划。 这为您提供了大量可用于分析的信息。
一切都取决于您如何（好）编写 SQL 以及您的数据库针对您正在执行的操作而设计得如何。 尝试使用解释计划函数来查看数据库将如何执行事情。这。你可以计算出大O
如果您使用递归和窗口函数编写查询，SQL 就是图灵完备的。所以这个问题有点像询问 C 程序的 big-O 复杂性，并且完全取决于您的应用程序。
唯一的区别是 SQL 相当擅长为您更改算法，并自动找到比简单代码好得多的计划，只要您允许它访问正确的数据结构。