informix建临时表索引

对于特殊字段,比如外键,主键,在不知道外键主键名的情况下,需要如下操作
select constrname from sysconstraints where constrtype=‘R‘ and tabid= ( select tabid from systables where tabname = ‘tst_1‘ ) ;   ----‘R‘查找外键,‘P‘查找主键
------针对informix数据库-----------------------------------------------------------   
ALTER   TABLE   yourtable   DROP   CONSTRAINT   constrname;   
yourtable   :你要删除的约束所在的表名称;   
constrname   :你要删除的约束名称;   
constrname的获得:   
在informix数据库中有一个系统表:sysconstraints   
该表中存储了数据库所有的约束的基本信息:   
constrid   :约束标示   
constrname   :约束名称   
owner   :owner的用户名称   
tabid   :表标示   
constrtype   :约束类型   
          取值:C(check   constraint)、P(Primary   key)、R(Referential)、U(Unique)、N(Not   Null)其中R则是你所需要的。   
idxname   :索引名称   
根据tabid从另一个系统表systables中检索tabname。

希望对你有帮助。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

对于特殊字段,比如外键,主键,在不知道外键主键名的情况下,需要如下操作
select constrname from sysconstraints where constrtype=‘R‘ and tabid= ( select tabid from systables where tabname = ‘tst_1‘ ) ;   ----‘R‘查找外键,‘P‘查找主键
------针对informix数据库-----------------------------------------------------------   
ALTER   TABLE   yourtable   DROP   CONSTRAINT   constrname;   
yourtable   :你要删除的约束所在的表名称;   
constrname   :你要删除的约束名称;   
constrname的获得:   
在informix数据库中有一个系统表:sysconstraints   
该表中存储了数据库所有的约束的基本信息:   
constrid   :约束标示   
constrname   :约束名称   
owner   wner的用户名称   
tabid   :表标示   
constrtype   :约束类型   
          取值:C(check   constraint)、P(Primary   key)、R(Referential)、U(Unique)、N(Not   Null)其中R则是你所需要的。   
idxname   :索引名称   
根据tabid从另一个系统表systables中检索tabname

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

--查看索引定义
select dbms_metadata.get_ddl(‘INDEX‘,‘IDX_PG_HY_YDNSRXX_PGFAXH‘) from dual;

--在某个用户下找所有的索引     
    
  select   user_indexes.table_name,   user_indexes.index_name,uniqueness,   column_name     
  from   user_ind_columns,   user_indexes     
  where   user_ind_columns.index_name   =   user_indexes.index_name     
  and   user_ind_columns.table_name   =   user_indexes.table_name     
  order   by   user_indexes.table_type,   user_indexes.table_name,     
  user_indexes.index_name,   column_position;

--查看索引

select   INDEX_NAME,table_name ,COLUMN_NAME,INDEX_OWNER  from   dba_ind_columns   where   TABLE_NAME=‘PG_HY_YDNSRXX‘;  
 
--查找所有索引

select   *   from   all_indexes;

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

讨论这个之前;需要跟大家提到一个概念-“主键”;其实主键是一种特殊的唯一索引;当建立一个主键是;在系统中其实建立了一个不能为空的唯一索引。他和唯一索引的区别也就是不能为空这么一点了。因此他能做到唯一识别表中的一条记录的作用。索引都有索引名在create index  idx-name中定义;主键在定义是没有指定名称;但实际上系统会给自动命名一个unnn_nnn【n为数字】的一个名字。可以通过如下语句查得:【如查basetab_pps主键名字】

select constrname  from sysconstraints
where tabid in (select tabid from systables where tabname=basetab_pps);

下面可以谈谈如何恢复损坏得索引了:

1、  如果是普通得索引。这样就相对得简单了;删除并重建他就可以了。

drop  index  idx-name;
create index   idx-name  on  tabname(colname1,colname2…);

2、  如果是主键损坏;同样可以删除并重建他。

A、    删除主键
select constrname  from sysconstraints 
where tabid in (select tabid from systables where tabname=tabname);
alter  table  tabname  drop  constraint  cons_name;

B、 重建主键
alter table   basetab_pps  add  constraint primary key (colname1,colname2…);

3、如果重建都有问题;那么最后一招;只有将表重建了。导出数据和建表语句;删除表、重建表、重建索引。。。

关于索引的问题最后讨论一下;统计更新【upadte statistics】的作用

举个简单的例子:

试验一:
在dbaccess 中执行如下操作:
drop table t1 
create table t1 (c1  int,c2 char(10));
create  index i_t1 on t1 (c1);
insert into t1 values (1,1);
insert into t1 values (2,1);
insert into t1 values (3,1);

set explain on   --
select * from t1 where c1 = 2;

在运行目录下的sqexplain.out文件中看到:

QUERY:

------

select * from t1 where c1 = 2
Estimated Cost: 2
Estimated # of Rows Returned: 2
1) smpmml.t1: SEQUENTIAL SCAN
    Filters: smpmml.t1.c1 = 2

试验二:
在dbaccess 中执行如下操作:
drop table t1 
create table t1 (c1  int,c2 char(10));
create  index i_t1 on t1 (c1);
insert into t1 values (1,1);
insert into t1 values (2,1);
insert into t1 values (3,1);

update statistics for table t1;
set explain on 
select * from t1 where c1 = 2;

在运行目录下的sqexplain.out文件中看到:

QUERY:
------
select * from t1 where c1 = 2
Estimated Cost: 1
Estimated # of Rows Returned: 1

1) smpmml.t1: INDEX PATH
    (1) Index Keys: c1
       Lower Index Filter: smpmml.t1.c1 = 2

试验三:
在dbaccess 中执行如下操作:
drop table t1 
create table t1 (c1  int,c2 char(10));
create unique index i_t1 on t1 (c1);
insert into t1 values (1,1);
insert into t1 values (2,1);
insert into t1 values (3,1);

set explain on 
select * from t1 where c1 = 2;

在运行目录下的sqexplain.out文件中看到:
QUERY:
------
select * from t1 where c1 = 2
Estimated Cost: 2
Estimated # of Rows Returned: 1

1) smpmml.t1: INDEX PATH
    (1) Index Keys: c1
       Lower Index Filter: smpmml.t1.c1 = 2

分析一下:
试验一:建立了一般的索引;对按索引字段进行搜索;但是没有用到刚建立起来的索引。按全表扫描SEQUENTIAL SCAN进行查找。
试验二:建立了一般的索引;并且进行了统计更新后;对按索引字段进行搜索;使用到建立起来的索引。INDEX PATH
试验三:建立了唯一索引;对按索引字段进行搜索;使用到了刚建立起来的索引。INDEX PATH;显然如果建立了主键【特殊的唯一索引】;现象将是一样的。
    我们可以这样说;如果建立了主键或唯一索引;立马就能生效;这也是我们在WIN的安装、升级或维护过程中建立了一些表没有做统计更新同样能用到索引的原因。而如果建立的不是唯一索引;就需要执行统计更新才能用到索引。

实际上统计更新除了能决定是否使用到索引外;还有使用这些统计信息如何使用索引及其他方式进行查询的目的。具体如何使用这些信息来决定查询路径就比较底层了。只知道通过执行update statistics命令,就可以使系统表systables、sysdistrib、syscolumns、sysindexes等表内的记录数、表空间的页数、记录长度、字段不同值个数、字段值的分布、索引的层数等信息得到更新。而服务器在进行语法分析后能通过查询优化器根据这些统计信息找到最有效的执行SQL的路径。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Informix系统表说明

systables:描述数据库中的很张表;   
  syscolumns:描述数据库中表的列;   
  sysindexes:描述数据库中列的索引;   
  sysfragments:存储了分段索引的片段信息;   
  sysfragauth:表识别列级权限;   
  sysviews:描述了数据库中定义的每个视图;   
  sysdpend:描述了视图是如何依赖其他视图和表的;   
  syssyntable:定义每一个同义词及其所代表的对象;   
  sysconstraints:记录了加载在数据库表列上的约束;   
  sysreferences:列出了放置在数据库上的参照约束,它为数据库的每个参照约束建立一行   
  syscoldepend:记录了涉及检查约束的所有列,包括在约束中每列都会在syscoldepend表中创建一行;   
  sysprocedures:存放数据库中每个过程的特征;   
  sysprocplan:装载了过程执行所需的两项内容(执行计划或查询计划、附属列表);   
  sysprocauth:描述授予存储过程的权限;   
  systriggers:装载了关于触发器的信息;   
  sysblobs:确定BLOB列的存储位置;   
  sysroleauth:描述授予用户的角色;   
  sysobjstate:存储了关于数据库对象的状态信息;   
  sysvlolations:违例或诊断表; 
  sysdefaults:描述数据库中表的列的默认值;

时间: 2024-11-05 23:37:54

informix建临时表索引的相关文章

SQL 语句调优 where 条件 数据类型 临时表 索引

基本原则 避免全表扫描 建立索引 尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理 尽量避免大事务操作,提高系统并发能力 使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效.尽量避免使用游标,因为游标的效率较差. where 后的条件 应尽量避免在 where 子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描. 应尽量避免在 where 子句中使用 or 来连接条件,可以考虑使用union 代替 in 和

如何加快建 index 索引 的时间

朋友在500w的表上建索引,半个小时都没有结束.所以就讨论如何提速. 一.先来看一下创建索引要做哪些操作:1. 把index key的data 读到内存==>如果data 没在db_cache 中,这时候很容易有大量的db file scatter read wait 2. 对index key的data 作排序==>sort_area_size 或者pga_aggregate_target 不够大的情况下,需要做 disk sort, 会有大量的driect path read/write

Mysql建了索引查询很慢

遇到一个问题,有几个结构一个的查询,表的索引建的也一样,但是有的查询很快,有的却很慢,需要半分钟以上才能执行完. 查看执行计划,并没有什么区别.找了很久原因才发现是主查询和子查询所涉及的表的字符编码不一致.改为一致后,问题解决. sql如下: delete from t_diag_detection WHERE reportName NOT IN (SELECT reportName FROM t_diag_reportinfo) 原因是 t_diag_detection表的字符编码是utf8m

MySQL巧建sum索引帮我们提高至少100%的效率

有两个表,表a CREATE TABLE `a` ( `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT, `fid` smallint(6) unsigned NOT NULL DEFAULT '0', `cnt` smallint(6) unsigned NOT NULL DEFAULT '0', ... ... ... PRIMARY KEY (`id`), KEY `idx_fid` (`fid`), ) ENGINE=MyISAM DE

已有数据的表-建联合索引

清理重复数据,建立联合唯一索引 1. 查看重复数据 SELECT * FROM holiday_focamobilerel WHERE (cardnumber, mobile) IN (SELECT cardnumber, mobile FROM holiday_focamobilerel GROUP BY cardnumber, mobile HAVING COUNT(1) > 1); 2. 删除重复数据 - 保留order_id and sub_order_id不为空的 - 如果order_

数据库查询优化——给临时表建索引

平时查询数据库时为了查询更加快速,一般都会用到临时表,如select * into #t from tableA ,但是如果数据过大,但但用临时可能也很慢,这时候可以给临时表建个索引,如CREATE INDEX IX_TempTable ON #T(字段1,字段2,字段3).如果临时表字段未知的时候怎么建立索引呢,可以用以下sql把临时表的所有字段查出来,给所有字段建立索引 DECLARE @COL VARCHAR(1000)SET @COL = ''SELECT @COL = @COL + C

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

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

Mysql建表与索引使用规范详解

一. MySQL建表,字段需设置为非空,需设置字段默认值. 二. MySQL建表,字段需NULL时,需设置字段默认值,默认值不为NULL. 三. MySQL建表,如果字段等价于外键,应在该字段加索引. 四. MySQL建表,不同表之间的相同属性值的字段,列类型,类型长度,是否非空,是否默认值,需保持一致,否则无法正确使用索引进行关联对比. 五. MySQL使用时,一条SQL语句只能使用一个表的一个索引.所有的字段类型都可以索引,多列索引的属性最多15个. 六. 如果可以在多个索引中进行选择,My

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.