如何避免标量子查询

   先说结论，那就是从表设计开始。所有数据库对象由DBA批准才能建立（当然这些对象是明确需求后对应建立的），否则基本不可能避免。

   那么什么是标量子查询。看个示例：select  a,b,c (select d from t1 where t1.id=t2.id and rownum=1) ,e from  t2 .类似这样的在select之后，from之前有一个子查询的就是标量子查询，特点是返回单个值的子查询。

   标量子查询的危害就是多了一个表关联。在真实的开发环境中，一个SQL可能带了7-8个标量子查询。那么就会多关联7-8张表。无形中增加了运算量。

   标量子查询的危害还有可能因为关联表的时候，缺乏对应的索引导致部分表产生全表扫描。

   标量子查询的危害还有可读性差。

   标量子查询产生的原因只有两个：需求有问题或者设计有问题。

   例如：A表和B表。A与B是1对2的关系。

标量子查询是返回单个值。所以可能有如下两种可能。但是可以看到这两种返回的结果是不一样的。因为在这种数据条件下，其实是不适合用标量子查询的。否则逻辑就错了。而在现实工作中我已经发现多次，其实业务逻辑就是错的案例了。

而真正可能需要用到标量子查询的是这样的数据样例。B表上有一列，这一列对于关联的数据来说都是一样的，取任意一行或者最大值，最小值都一样。

那么SQL可能会写成这种。

其实这样写虽然目的达到了，但是多关联了一个表。其主要原因是表设计的时候问题。如果需求是需要在A表这些列展示的时候需要CODE列，那么表设计的时候CODE就应该在A表上。（B表冗余一下也可以）

千万不要以为就一个表无所谓，但是其实当SQL复杂的时候性能就会下降。

经常看到各个数据库的打榜和性能指标，但是实际工作中连这些性能有时候的百分之一都达不到，就是因为需求和设计不匹配导致的。

更多类似的，可以期待我马上要提交出版社的书。预计元旦前后能上市。