对许多DBA来说，SQL的强化可以从控制系统微观、资料库微观、SQL句子微观进行改良。但这些都是控制技术微观的改良，在具体内容的销售业务情景中，T8300来强化也是一类十分值得称赞尊崇的方式。有一类讲法是调需著重所有人，具体内容难题具体内容看待，T8300使难题处置更有前瞻性，这样控制技术破冰枭女。
归纳了许多的Listary事例，也辨认出了许多难题，很多SQL难题转头上看是较为合情理的严重错误，稍作更动就能运转在秒级，很多即使是秒级到微秒级的急剧提升等；无论Listary的改良数不清，从DBA的视角上看，许多难题都是如前所述天然资源来Listary的，比如说加进检索、减少I/O、减少CPU耗用以及提升CPU利用效率等。如果有时从销售业务视角来下工夫，可能某种意义上效用要更好于如前所述天然资源/付出的Listary。
前段时间顾客意见反馈有四条SQL句子的I/O耗用极高，期望我们能殿中提议。
SQL句子十分钟，运转时间在9秒钟，运转振幅也是挺高的，平均值留下来一个半小时100次。
句子如附注所示：
select product_name from service_details where subscriber_no in (select subscriber_no from subscriber where prim_resource_val = :1 and sub_status = A) and product_status = A ;
其中service_details是一亿级的大表，subscriber是一百万级的表，但prim_resource_val表头不是检索列，因此引致subscriber表走了全表扫描器，见附注：
继续执行方案如附注所示：
Predicate Information (identified by operation id):
—————————————————
3 – filter(PRIM_RESOURCE_VAL=:1 AND SUB_STATUS=A)
4 – access(SUBSCRIBER_NO=SUBSCRIBER_NO)
5 – filter(PRODUCT_STATUS=A)
如果从天然资源/付出的视角上看，思路便是加进对应的检索。但这个表是产品线中统一规划的，要加入检索还是很不容易的。
如果没有其他的Listary思路，并行也可以，但它是一把双刃剑，相对来说速度会高一些，但I/O和CPU的耗用会较为高，对于继续执行如此频繁的句子来说，使用多个并行对控制系统负载是极高的。
看着SQL句子较为简单，但无从下手也很多让人着急。资料库的视角所做的一些调整可能奏效不大，于是就想看看从销售业务视角能做点什么。
查看SQL句子。
select product_name from service_details where subscriber_no in (select subscriber_ no from subscriber where prim_resource_val = :1 and sub_status = A) and product_status = A ;
SQL句子中prim_resource_val与我们使用的手机号码很多类似，这样一个号码为什么没有加入检索，从销售业务的视角来考虑，可能是有做号码变更之类操作时这个号码列变化较为频繁。而保持不变的就是subscriber_no。类似我们去银行办理销售业务时显示的顾客号，这个表头就是主键列。
可能有的人有多个天然资源号，比如说有机顶盒号、手机号等，在这个时候手机号就是主要的天然资源号。
下面来分析为什么产品线中没有规划给resource_value作为检索列，也是考虑了后期的一些变更。这个列变化还是较为频繁，这样考虑也就有一定的道理。
因为对这部分的销售业务较为熟悉，因此辨认出所需要的天然资源号，完全可以从一个独立的表subscriber_resource中得到更完整的信息。
这个表也是亿级的表，但根据天然资源号来查找subscriber可以走index range scan，得到数据也要快许多。
subscriber_resource中存放着用户所使用的各类天然资源信息，从这个表里直接映射resource_value得到的用户信息很有限。因为根据条件只需要激活状态的用户，那么我们完全可以在得到一个很简单的用户列表后直接过滤用户状态，这样就能得到所需要的信息。最后做了如附注所示的改动，把天然资源表关联进来。
select product_name
from service_details ser
where subscriber_no in (select subscriber_no
from subscriber
where sub_status = A
and (subscriber_no, prim_resource_tp) in (select subscriber_no, resource_type from subcriber_resource where resource_value=:1)
)
and soc_status = A
查看如附注所示继续执行方案，继续执行的检索还是较为高效的。
Predicate Information (identified by operation id):
—————————————————
9 – access(RESOURCE_VALUE=:1)
10 – access(SUBSCRIBER_NO=SUBSCRIBER_NO)
11 – filter(SUB_STATUS=A AND PRIM_RESOURCE_TP=RESOURCE_TYPE)
12 – access(SUBSCRIBER_NO=SUBSCRIBER_NO)
13 – filter(PRODUCT_STATUS=A)
最后在备份库做相关的测试，继续执行时间都在微秒级。
因此很多时候从销售业务的视角来Listary可能会有意想不到的收获。还有几个类似的句子，继续执行时间在分钟级，调整成类似的形式之后，都在微秒级完成了数据查询。
