用户发给 OBServer 节点的 SQL，可以粗略分为两类：一类 SQL 访问和操作的数据量小，所以执行很快；另一类 SQL 要访问大量的数据或者要写入大量数据，所有执行耗时长。我们把第二类耗时长的 SQL 叫做大查询。
大查询的特殊处理基于一个直观的用户效用假设，从影响用户数和延迟的 QoS（Quality of Service）要求来合理猜想：1000 个小查询被延迟的影响要远大于 1 个大查询被延迟。换言之，与其花 1s 时间处理一个大查询，不如把同样的 CPU 时间用来处理 1000 个小查询。OceanBase分布式数据库-海量数据 笔笔算数
文档里边不是这个意思吧，文档中的这个用户效用假设是基于影响面和延迟来说的，比如1000个小查询可能涉及的是1000个c端用户发起的请求，因为本身是小查询，这种请求在业务侧响应的速度就应该快，换句话说，业务侧很可能在小查询的超时阈值设置的比较小。（当然这些都是合理的假设）
基于这些假设，ob在cpu繁忙的时候针对大查询就可以的去挂起，一来大查询本身非常消耗cpu，挂起大查询对cpu缓解最有效，释放出的cpu可以执行更多的小查询；二来基于上面的假设，挂起大查询影响面会小一些。举个例子：挂起大查询，省下来0.01 c ,只影响一个用户，而如果要达到挂起大查询同等的效果，可能需要挂起1000个小查询，影响1000个用户。
上面所有的说法针对的是线程挂起的抉择策略。
