-
1。关于计数
看到一些关于计数（*）和计数（列）的在线文章，计数（列）比计数（*）更有效吗
事实上，人们认为计数（*）和计数（列）根本不可比。计数（*）计算表的总数，而计数（列）则计算非空记录的数量。
但我们可以把它与实验相比较。
首先创建测试表：
下拉表测试清除；
创建测试表为SELECT * FROM dba_objects；
更新测试集object_id =行号；
设置定时
设置线宽1000
使AutoTrace
实施
从测试中选择计数（*）；
select count（object_id）测试；
找到同一时间，他们有同样的效率吗
我们试图创造一个柱子上object_id指数
创建测试指标idx_object_id（object_id）；
然后再执行它
从测试中选择计数（*）；
select count（object_id）测试；
发现计算速度（object_id）显著高于计数（*）。这是因为数（object_id）可以用索引，所以效率有了很大的提高
我们修改的object_id列属性
修改表的测试修改object_id不空；
然后再执行它
从测试中选择计数（*）；
select count（object_id）测试；
发现它们的速度同样快，计数（*）也可用于索引。
事实上，效率比较的前提是两种说法的写作应该是对等的，这两种文字是不等价的，因此没有可比性。
对于Oracle优化器，我们可以发现统计数据中计数的不同列是不同的。一般的趋势是，访问的代价越大，列的偏移量决定访问的性能就越高。计数（*）的开销独立于偏移量。因此，在某些情况下，计数（*）是最快的。
两。关于存在和存在
关于存在和存在的大多数陈述都是，效率高于存在，所以存在必须被存在等代替，但它真的是这样吗
让我们做一个实验。
在Oracle 10g中；
SELECT * FROM部门工资不在（选择上从EMP）；
SELECT * FROM部门不存在（选择从EMP在EMP表。表dept.deptno）；
我们发现存在确实比效率更有效。
但是我们再次声明如下
SELECT * FROM部门工资不在（选择上从EMP的地方）；
你会发现，在非空约束条件下，存在和存在的效率是相同的。
看到三语句执行计划，你会发现没有非空约束和存在语句都采用了反半连接算法，所以效率是一样的，但在语句中没有非空约束使用过滤器，而不是反算法，所以效率较低。
因此，我们可以得出结论，在Oracle 10g中，如果能够保证非空，那么在约束中可以使用反半连接算法，这与此时的效率是一样的。
Oracle 11g：
SELECT * FROM部门工资不在（选择上从EMP）；
SELECT * FROM部门不存在（选择从EMP在EMP表。表dept.deptno）；
我们发现，这两个语句的效率是相同的，这是看到的执行计划一样。原来，Oracle优化了11g，所以效率和存在是相同的。
由此我们可以得出结论，在11g，使用效率和存在是相同的，因为他们都是更有效的反算法。
三。尺寸表的连接顺序
在互联网上，我们可以看到许多这样的文章。当我们执行多个表查询时，我们使用一个小表或交叉表来构成一个基本表，并把它放在后面，大表放在后面，因为表的访问顺序是从右到左。
但真的是这样吗
我们可以做实验验证（这里的测试环境是Oracle 11g）：
创建表tab_big为SELECT * FROM dba_objects哪里rownum <= 30000；
创建表tab_small为SELECT * FROM dba_objects哪里rownum <= 10；
AutoTrace traceonly
设置线宽1000
设置定时
select count（*）从tab_big，tab_small；
select count（*）从tab_small，tab_big；
当我们查看执行计划时，我们可以发现这两种语句的效率是一样的。多表查询与表的顺序和效率无关吗
我们正在执行以下声明：
选择 / * * / +规则数（*）从tab_big，tab_small；
选择 / * * / +规则数（*）从tab_small，tab_big；
我们可以清楚地发现，右表中的小表、左表中的大表，查询效率要高得多。
事实上，在基于规则的时代，查询效率与表的顺序有关。小表或交叉表在左边和更大的表上效率更高，但现在基本上是一个基于成本的时代，所以大小表的顺序与效率无关，Oracle优化器会自动优化效率。
四和WHERE子句中连接条件的顺序
在基于规则的时代，Oracle采用自下而上的顺序来分析WHERE子句。根据这个原则，我们通常在后面放最少行数的表，在WHERE子句放在后面的带过滤条件的子句。
但是现在，基于成本的时代，这种优化是由Oracle优化器优化的，因此表的顺序和条件序列不会影响我们的查询效率。