慢查询默认被定义为100ms，这个时间是如何定义的？作为oracle来讲100ms的sql并不在少数，而作为分布式数据库感觉100ms的语句应该也不在少数
这个我有查到，只是对这个慢SQL的阈值应该设置为多少合适比较纠结，按说作为分布式数据库网络上的延迟肯定大于集中式数据库，但对于oracle这种集中式的数据库来说100ms也不完全能定义为慢SQL，所以OB的慢SQL到底应该定义为多少ms比较合适呢？
根据具体的业务场景和实际情况来综合考虑。
对于一些对响应时间要求非常高的业务场景，慢SQL的定义可能会更严格，比如响应时间超过50ms就可以认为是慢SQL了。
其实是看业务对查询时间的容忍度，比如：业务认为超过10ms就觉得慢，那就可以定义成10ms，如果10S都能接受，那完全可以定义成10S
就是一个拍的值，根据需要自己调整，云上是500ms
默认定义的100ms显然不是很妥当
这个需要结合业务的实际情况进行设置，还有这个设置是属于租户级设置是吧。
高了还是低了
不同业务场景下不一样，对一个事务场景和分析场景的要求应该不一样吧
SQL 性能就跟冰山一样，SQL优化的目标跟你能投入的资源和精力有关，所以一般就是解决露出水面的那部分问题。换做DB术语就是解决 TOP N SQL. TOP 1 解决不了就拿 TOP 2 开刀。以此类推。露出多少这个就看用户自己的选择。
TOP N SQL 是按照某个维度去排序的。像 ORACLE AWR 里 TOP SQL 维度就非常多。 OB 里也有很多维度。
慢 SQL 也是 TOP N SQL，维度是 SQL 的执行时间，只不过还还有个参数设置一下慢SQL的门槛。这最早是从 MySQL 引入的。因为 MySQL 的 SQL 诊断能力非常的差，只有这一个维度。多长算慢，取决于客户的业务，客户优化人员的精力和资源。
所以，OB 有多个维度的TOP N SQL 展示，不要只着眼于 慢 SQL。 优化 SQL 的逻辑读、物理读，可以降低数据库的CPU或 IO 资源消耗，同样有可能降低 SQL 的执行时间。
慢SQL 从一定意义上取决于你想不想优化它 。我们的是2秒。 一般都是 1秒。
我感觉作为分布式数据库，100ms默认是低了，建议300~500ms