临时表

这些天在做一个表的导入操作， 操作步骤：先验证第一个工作表数据的正确性。如果数据正确，导入到中间的一个临时表中。然后再通过，存储过程导入到真实表中。 第二张，第三张工作表也是一样的。 如果有一个表的数据有问题，则要删除。真实表，和临时表里的全部数据。 这样就会出现一个问题.现在真实表的数据现在有190825条数据。只有主键索引。如果现在导入第二个工作表时，在验证数据正确性时。发现数据缺失。或其它数据问题。此execl 不能再导入了。要删除导入到真实表的1028条数据，和临时表里的全部数据。现在主要问题出现在.在真实表中删除数据时。会出现要30到1小时，有时更多的时间。出现假死。导 入面面，一直在那里运也不运的还会出现用户等到不了，就关了浏览器。（浏览器关闭后，导入的操作就会停止）导致数据里出现脏数据。再次导入时。会一直报错，说有约束重 复。 解决方案： 1 启用历史归档表，所有操作的归档数据放到另一个表里，这样，真实操作表的数据就会少好多，如果出现异常，删除的速度也会很快 2 验证一个工作表，导入一个工作表的数据到临时表中。再去验证第二个工作表，如果没有问题再导入到临时表中。真到最后全部工作表都导入到临时表中.再用存储过程导入到真实表中。这样如果中间有一个工作表的数据有问题，删除也只是删除临时表里的数据，量不会很大，并且这个系统操作的人也不是很多。这样肯定就行了. 主要是，删除

1、视图是一个虚拟表，可以认为对原表封装了一下，一般情况下，可以把视图当做表来对待。 2、视图的实现由两种策略：临时表算法与合并算法。临时表算法：把视图对原表的查询结果放在一个临时表中，以后对视图的操作就是对临时表的操作。合并算法：把对试图的操作转化为对原表的操作。 3、举例来说，mysql> create view bigAgeStuView as select * from stu where age>25; 对于查询 mysql> select * from bigAgeStuView where age<28; 如果采用临时表算法，Mysql会把select * from stu where age>25的结果放入一张临时表，再操作临时表，查找age>28 如果采用合并算法，Mysql会把对视图的查询转化为select * from bigAgeStuView where 25<age and age<28; 显然，临时表算法会存在严重的性能问题。 4、对于create view bigAgeStuView as select * from stu where age>25; 可以指定视图的算法，格式如下： mysql> create algorithm=temptable view bigAgeStuView as select * from stu where age>

现观察线上系统运行发现，线上某些业务查询存在等待时间长问题，后核查发现，部分问题出现在对数据库操作上Cost大部分时间，后根据网上各位前辈提供的优化技巧解决大部分问题，现写下本篇文章，一来巩固加深自己学习的优化技巧，二来方便正在为sql优化迷茫的猿友们提供一下思路和方法，共同进步，一起成长~ 1、现状描述 sql执行时间长、数据查询慢 2、问题对象 sql执行语句（特别是多表多条件关联查询数据） 3、理论知识 1、Oracle优化器 sql优化器：sql数据库中的优化器又叫查询优化器（QueryOptimizer）。它是SQL分析和执行的优化工具，它负责生成、制定SQL的执行计划。 sql优化器优化方式 基于规则的优化方式(Rule-BasedOptimization,简称为RBO) 它根据指定的规则顺序，对指定的表进行执行计划的选择。它着一套严格的使用规则，只要你按照它去写SQL语句，无论数据表中的 内容怎样，也不会影响到你的“执行计划”，也就是说RB对数据不“敏感”。要求开发人员了解RBO的各项细则。在sql 10g中完全被CBO取代。 基于代价的优化方式(Cost-Based Optimization,简称为CBO)。 CBO是一种比RBO更加合理、可靠的优化器，它是从sql 8中开始引入，在sql10g中完全取代RBO。CBO是计算各种可能“执行 计划”的“代价”

特别说明：该案例引自谭老师的《让Oracle跑的更快2》。 实验说明： 该实验将用到在线数据库YFT1，离线数据库YFT2。 实验操作： 一、分别在两个数据库中创建一个分区表，并为每个分区创建一个单独的表空间，以便于和临时表做分区交换。 1.1、在数据库YFT1中： Create Tablespace 1 [ oracle@node2 ~ ] $ env | grep ORA 2 ORACLE_SID = YFT1 3 ORACLE_BASE =/ u01 / app / oracle 4 ORACLE_HOME =/ u01 / app / oracle / product / 11.2 . 0 / db_1 5 [ oracle@node2 ~ ] $ sqlplus / nolog 6 7 SQL * Plus: Release 11.2 . 0.1 . 0 Production on Wed Dec 19 13 : 56 : 53 2012 8 9 Copyright (c) 1982 , 2009 , Oracle. All rights reserved. 10 11 SQL > conn / as sysdba 12 Connected. 13 SQL > alter system set db_create_file_dest = ' /u01/app/oracle

一、实验说明： 操作系统：rhel 5.4 x86 数据库：Oracle 11g R2 实验说明:该实验参照了谭老师的《让Oracle跑的更快2》中的一个案例。 二、在数据库中创建带加载数据的分区表及索引 ----------创建一个包含3个分区的分区表，分区的字段是一个时间字段，分别存放2011年、2012年和之后的数据。----- 1 SQL > create table jack_test(id int ,name varchar2 ( 60 ),created date) 2 2 partition by range(created) 3 3 ( 4 4 partition p2011 values less than(to_date( ' 2012-01-01 ' , ' yyyy-mm-dd ' )), 5 5 partition p2012 values less than(to_date( ' 2013-01-01 ' , ' yyyy-mm-dd ' )), 6 6 partition pmax values less than (maxvalue) 7 7 ); 8 9 Table created. ----------创建全文索引------------------------------------------------------------------

一、临时表的介绍： Oracle的临时表只存在于某个会话或者事物的生命周期里，此时临时表中的数据只对当前这个会话可见。 临时表经常被用于存放一个操作的中间数据(数据处理的中间环节)。 临时表由于不产生redo，能够提高数据操作的性能。 二、临时表的创建： 创建Oracle临时表，可以用两种类型的临时表： a、会话级的临时表 b、事务级的临时表 2.1、会话级的临时表因为这个临时表中的数据和你的当前会话有关系，当你当前SESSION不退出的情况下，临时表中的数据就还存在，而当你退出当前SESSION的时候，临时表中的数据就全部没有了，当然这个时候你如果以另外一个SESSION登陆的时候是看不到另外一个SESSION中插入到临时表中的数据的。即两个不同的SESSION所插入的数据是互不相干的。当某一个SESSION退出之后临时表中的数据就被截断(truncate table，即数据清空)了。会话级的临时表的创建方法： ----创建会话级临时表jack_tmp_session---- 1 SQL > create global temporary table jack_tmp_session on commit preserve rows as select * from dba_objects where 1 = 2 ; 2 3 表已创建。 4 5 SQL > select table

SELECT * FROM tempdb..syscolumns WHERE (id = OBJECT_ID ( ' tempdb..#temp ' )) 得到正常表列数 SELECT * FROM syscolumns WHERE (id = OBJECT_ID ( 'tablename' )) 转载于:https://www.cnblogs.com/hubj/archive/2008/08/29/1279075.html 来源： https://blog.csdn.net/weixin_30527551/article/details/99042683

文章目录 数据库命令规范 数据库基本设计规范 数据库字段设计规范 索引设计规范 常见索引列建议 如何选择索引列的顺序 避免建立冗余索引和重复索引 优先考虑覆盖索引 索引SET规范 数据库SQL开发规范 数据库操作行为规范 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） 数据库对象的命名要能做到见名识意，并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀，备份表必须以bak_为前缀并以日期(时间戳)为后缀 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） 数据库基本设计规范 1、所有表必须使用Innodb存储引擎 没有特殊要求（即Innodb无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用Innodb存储引擎（mysql5.5之前默认使用Myisam，5.6以后默认的为Innodb）Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好 2、数据库和表的字符集统一使用UTF8MB4 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效 3、所有表和字段都需要添加注释

【问题现象】 线上mysql数据库爆出一个慢查询，DBA观察发现，查询时服务器IO飙升，IO占用率达到100%， 执行时间长达7s左右。 SQL语句如下： SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROMgm_game g LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ; 【问题分析】 使用explain查看执行计划，结果如下： 这条sql语句的问题其实还是比较明显的： 查询了大量数据(包括数据条数、以及g.* )，然后使用临时表order by，但最终又只返回了20条数据。 DBA观察到的IO高，是因为sql语句生成了一个巨大的临时表，内存放不下，于是全部拷贝到磁盘，导致IO飙升。 【优化方案】 优化的总体思路是拆分sql，

如何优化大数据量表的查询，尤其是两个表关联查询。 这里提供一种解决思路。 采用临时表或临时表变量，把两个表或者其中一个表筛选出一部分数据放到临时表中，然后再进行连接查询。 临时表存储于内存中，只用于做查询操作，避免了其他用户的增、删操作锁定表的性能消耗。 在执行表查询操作的时候，要加s锁，被加了s锁的表，其他用户只能进行查询操作，而不能进行修改删除操作。也就是说：被加了s锁的表，还能被s锁，但不能加x锁。 创建临时表就能及时释放s锁，以供后来用户使用。一定程度防止耗时的查询阻塞其他用户。 基本的封锁类型有两种 排它锁(X锁)和共享锁(S锁). 所谓X锁,是事务T对数据A加上X锁时,只允许事务T读取和修改数据A,... 所谓S锁,是事务T对数据A加上S锁时,其他事务只能再对数据A加S锁,而不能加X锁,直到T释放A上的S锁 若事务T对数据对象A加了S锁,则T就可以对A进行读取,但不能进行更新(S锁因此又称为读锁),在T释放A上的S锁以前,其他事务可以再对A加S锁,但不能加X锁,从而可以读取A,但不能更新A. 还有一种解决大量数据的思路是分割表。 对于过千万的数据，往往不会存储到一张表中，而是分割开来。 如果每天都生成大量的数据，可以把此表按日期进行拆分，创建一触发器，定点把每天的数据导入到带日期的历史表中，这些表专供查询。 这样的话虽然总记录有几千万，但分到不同的表中，数据就小了很多