V7核心系统全表提数

核心系统提数

SELECT * FROM WEB_PLY_BASE A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_CVRG A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_APPLICANT A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_INSURED A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_TGT A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_TGT_OBJ A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_ENT_TGT A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_ACCTINFO A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_BNFC A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_CI A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_FEE A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_PAY A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_APP_GRP_MEMBER A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_EDR_GRP_MEMBER A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT * FROM WEB_PLY_CARGO A WHERE A.C_PLY_NO = ‘&plyno‘; --02
SELECT * FROM WEB_PLY_CARGO_LIST A WHERE A.C_PLY_NO = ‘&plyno‘; --02

SELECT * FROM WEB_APP_BASE A WHERE A.C_PLY_NO = ‘&plyno‘;
SELECT *
  FROM WEB_APP_CVRG A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_APPLICANT A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_INSURED A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_TGT A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_TGT_OBJ A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_ENT_TGT A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_ACCTINFO A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_BNFC A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_CI A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_FEE A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_APP_PAY A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘);
SELECT *
  FROM WEB_PLY_CARGO A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘); --02
SELECT *
  FROM WEB_PLY_CARGO_LIST A
 WHERE A.C_APP_NO IN
       (SELECT B.C_APP_NO FROM WEB_APP_BASE B WHERE B.C_PLY_NO = ‘&plyno‘); --02
时间: 2024-11-10 10:53:09

V7核心系统全表提数的相关文章

【功能测试技巧3】多表提数实践

1.表table_score结构如下:用来存储分数. 表table_no结构如下:用来存储相关合同号.签约号.保单号. 表table_base结构如下:用来存储基础数据: 我们现在想要取到三个表中以table_base为基础,与table_score,table_no关联的数据. 2.书写思路如下 (1)首先明确三个表中都有相同的字段apply_id.business_No (2)其中business_NO与apply_id是一一对应的. (3)其中table_base表中的一个apply_id

执行计划-数据访问方式(全表扫描与4种索引的方式)

执行计划 Oracle执行计划的相关概念: Rowid:系统给oracle数据的每行附加的一个伪列,包含数据表名称,数据库id,存储数据库id以及一个流水号等信息,rowid在行的生命周期内唯一. Recursive sql:为了执行用户语句,系统附加执行的额外操作语句,譬如对数据字典的维护等. Row source(行源):oracle执行步骤过程中,由上一个操作返回的符合条件的行的集合. Predicate(谓词):where后的限制条件. Driving table(驱动表):又称为连接的

SQL 数据优化索引建suo避免全表扫描

首先什么是全表扫描和索引扫描?全表扫描所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果.如果数据没建立索引. 无索引的情况下搜索数据的速度和占用内存就会比用索引的检索慢和高.下面是一个例子 1:无索引的情况 Product表,里面没有任何索引,如下图: 从上图中,我悲剧的看到了,物理读是9次,也就说明走了9次硬盘,你也可以想到,走硬盘的目的是为了拿数据,逻辑读有1636次,要注意的是这里 的”次“是“页”的意思,也就是在内存中走了1636个数据页,我用dbcc

避免全表扫描的sql优化

对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引:  .尝试下面的技巧以避免优化器错选了表扫描: ·   使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布. ·   对扫描的表使用FORCE INDEX告知MySQL,相对于使用给定的索引表扫描将非常耗时.            SELECT * FROM t1, t2 FORCE INDEX (index_for_column)             WHERE t1.

WHERE条件中or与union引起的全表扫描的问题

说起数据库的SQL语句执行效率的问题,就不得不提where条件语句中的or(逻辑或)引起的全表扫描问题,从而导致效率下降. 在以往绝大多数的资料中,大多数人的建议是使用 union 代替 or ,以解决由于使用了 OR 导致的全表扫描.然而,实际是不是如此呢?flymorn就拿5万多条数据的MSSQL数据库来测试. 在SQL Server查询分析器中键入如下代码: SET STATISTICS profile ONSET STATISTICS io ONSET STATISTICS time O

【大数据课堂0008】会引起全表扫描的几种SQL 以及sql优化

查询语句的时候尽量避免全表扫描,使用全扫描,索引扫描!会引起全表扫描的几种SQL如下 1.模糊查询效率很低: 原因:like本身效率就比较低,应该尽量避免查询条件使用like:对于like ‘%...%’(全模糊)这样的条件,是无法使用索引的,全表扫描自然效率很低:另外,由于匹配算法的关系,模糊查询的字段长度越大,模糊查询效率越低. 解决办法:首先尽量避免模糊查询,如果因为业务需要一定要使用模糊查询,则至少保证不要使用全模糊查询,对于右模糊查询,即like ‘…%’,是会使用索引的:左模糊lik

表访问方式---->全表扫描(Full Table Scans, FTS)

全表扫描(Full Table Scans, FTS) 全表扫描是指Oracle在访问目标表里的数据时,会从该表所占用的第一个区(EXTENT)的第一个块(BLOCK)开始扫描,一直扫描到该表的高水位线(HWM,High Water Mark),Oracle会对这期间读到的所有数据施加目标SQL的where条件中指定的过滤条件,最后只返回那些满足过滤条件的数据. 不是说全表扫描不好,事实上Oracle在做全表扫描操作时会使用多块读,ORACLE采用一次读入多个数据块 (database bloc

Atitit.mssql 数据库表记录数and 表体积大小统计

Atitit.mssql 数据库表记录数and 表体积大小统计 1. EXEC   sp_MSforeachtable   "EXECUTE   sp_spaceused   '?'" 最后一种方法是利用隐藏未公开的系统存储过程sp_MSforeachtable CREATE TABLE  #temp  (TableName  VARCHAR  (255),  RowCnt  INT) EXEC  sp_MSforeachtable  'INSERT  INTO  #temp  SEL

怎么对10亿数据量级的mongoDB作高效的全表扫描

转自:http://quentinxxz.iteye.com/blog/2149440 一.正常情况下,不应该有这种需求 首先,大家应该有个概念,标题中的这个问题,在大多情况下是一个伪命题,不应该被提出来.要知道,对于一般较大数据量的数据库,全表查询,这种操作一般情况下是不应该出现的,在做正常查询的时候,如果是范围查询,你至少应该要加上limit. 说一下,我的应用场景:用于全量建立搜索引擎的索引.这就是一种需要用到全表扫描的非一般情况.对于全表扫描的结果,我们没有排序要求. 二.情况说明 既然