一. IN和EXISTS比较 在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行查询.此时就会用到IN和EXISTS. 例如:查询departments表中存在的部门的人数. 1. 使用IN SQL> set timing on SQL> select employees.department_id,count(*)   2  from employees   3  where employees.department_id in (   4  select departmen

需求: 小表数据量20w条左右,大表数据量在4kw条左右,需要根据大表筛选出150w条左右的数据并关联更新小表中5k左右的数据. 性能问题: 对筛选条件中涉及的字段加index后,如下常规的update语句仍耗时半小时左右. UPDATE WMOCDCREPORT.DM_WM_TRADINGALL A SET ( A.RELATIONSHIPNO, A.PACKAGE ) = (SELECT B.RELATIONSHIPNO, CASE ' ' ' ') THEN 'BC' ') THEN 'P

原文:走向DBA[MSSQL篇] 针对大表 设计高效的存储过程[原理篇] 附最差性能sql语句进化过程客串 测试的结果在此处 本篇详解一下原理 设计背景 由于历史原因,线上库环境数据量及其庞大,很多千万级以上甚至过亿的表.目标是让N张互相关联的表 按照一张源表为基表,数据搬移归档 这里我们举例N为50 每张表数据5000W 最差性能sql进化客串 2表KeyName 字段意义 名称等相同 从bug01 表中取出前500条不在bug02 表中的数据 最差性能: SELECT TOP 500 a.K

前言 本节我们来分析LEFT JOIN和NOT EXISTS,简短的内容,深入的理解,Always to review the basics. LEFT JOIN...IS NULL和NOT EXISTS分析 之前我们已经分析过IN查询在处理空值时是基于三值逻辑,只要子查询中存在空值此时则没有任何数据返回,而LEFT JOIN和NOT EXISTS无论子查询中有无空值上处理都是一样的,当然比较重要的是利用LEFT JOIN...IS NULL来检查NULL.基于二者返回的结果集是一样的,下面我们

SQL  in与exists相关性能问题总结 in 和 exists in 和 exists的是DBA或开发人员日常工作学习中常用的基本运算符,今天我就这两个所带来的性能问题进行分析总结,方便自己与他人的后续学习与工作. 先来了解in 和 exists的性能区别: 如果主查询中的表较大且又有索引,子查询得出的结果集记录较少时,应该用in:反之如果外层的主查询记录较少,子查询中的表大,又有索引时使用exists. 举例说明: select * from A where A.ID in(select

前言 前面我们学习了NOT EXISTS和NOT IN的比较,当然少不了EXISTS和IN的比较,所以本节我们来学习EXISTS和IN的比较,简短的内容,深入的理解,Always to review the basics. 初步探讨EXISTS和IN 我们创建表Table1并且取出前面创建BigTable表中的六条数据并插入其中,同时有一条数据重复,如下: CREATE TABLE Table1 (IntCol UNIQUEIDENTIFIER) Insert into Table1 (IntC

给出两个表,A和B,A和B表的数据量, 当A小于B时,用exists select * from A where exists (select * from B where A.id=B.id) exists的实现,相当于外表循环,每次循环对内表进行查询? for i in A for j in B if j.id == i.id then .... 相反,如果A大于B的时候,则用in select * from A where id in (select id from B) 这种在逻辑上类似

看了该文章之后,很受启发,mysql在update时,一般也是先select.但注意,在Read Committed隔离级别下,如果没有使用索引,并不会锁住整个表, 还是只锁住满足查询条件的记录而已.使用索引的最佳方式是使用主键,如果我们知道主键的范围(只要是精确范围的超集就可以了),那可以在查询 条件中加上主键的范围,这样查询时,会使用主键索引,就可以提高查询的速度了.这样,我们不用单独再给其它字段加索引,使用已知的索引就可以 加速查询,这种方式感觉很屌. 原文:http://blog.csd

看了该文章之后,很受启发,mysql在update时,一般也是先select.但注意,在Read Committed隔离级别下,如果没有使用索引,并不会锁住整个表, 还是只锁住满足查询条件的记录而已.使用索引的最佳方式是使用主键,如果我们知道主键的范围(只要是精确范围的超集就可以了),那可以在查询 条件中加上主键的范围,这样查询时,会使用主键索引,就可以提高查询的速度了.这样,我们不用单独再给其它字段加索引,使用已知的索引就可以 加速查询,这种方式感觉很屌. 原文:http://blog.csd

使用PL/SQL删除百万条记录的大表: 最近开发人员对测试环境数据库进行了压力测试,数据库中产生了大量的脏数据.有几张大表里数据量均在百万甚至千万条的记录数.开发人员现提出需求如下: 只清理其中的部分脏数据,不允许对这些表使用truncate操作.于是就有了下面的PL/SQL清理脚本: 1.编写删除数据表数据的脚本内容如下: $ cat data_del.sql  set serveroutput onshow serveroutputDECLARE V_LOGNUM NUMBER;V_NEED

Mysql 系列文章主页 =============== 本文将以真实例子来讲解小表驱动大表(In,Exists区别) 1 准备数据 1.1 创建表.函数.存储过程 参照  这篇(调用函数和存储过程批量插入数据)  文章中的第 1-7 步,注意,不要执行第8步 1.2 插入数据 现在来执行第8步. 1.2.1 向 Department 表中插入 100 条记录 CALL insert_dept(, ) 1.2.2 向 Employee 表中插入 100000 条记录 CALL insert_em

1. 优化原则:小表驱动大表,即小数据集驱动大数据集. select * from A where id in (select id from B) 等价于: for select id from B for select * from A where A.id = B.id 当B表的数据集必须小于A的数据集时,用in优于exists. select * from A where exists (select 1 from B where B.id = A.id) 等价于: for select

Hive中小表与大表关联(join)的性能分析 [转自:http://blog.sina.com.cn/s/blog_6ff05a2c01016j7n.html] 经常看到一些Hive优化的建议中说当小表与大表做关联时,把小表写在前面,这样可以使Hive的关联速度更快,提到的原因都是说因为小表可以先放到内存中,然后大表的每条记录再去内存中检测,最终完成关联查询.这样的原因看似合理,但是仔细推敲,又站不住脚跟. 多小的表算小表?如果所谓的小表在内存中放不下怎么办?我用2个只有几条记录的表做关联查询

//假设一个for循环 ; $i < ; $i++) { ; $i < ; $j++) { } } ; $i < ; $i++) { ; $i < ; $j++) { } } 看以上两个for循环,总共循环的次数是一样的.但是对于mysql数据库而言,并不是这样了,我们尽量选择第②个for循环,也就是小表驱动大表.数据库最伤神的就是跟程序链接释放,第一个建立了10000次链接,第二个建立了50次.假设链接了两次,每次做上百万次的数据集查询,查完就走,这样就只做了两次:相反建立了上百

要写出高效的SQL,那么必须必须得清楚SQL执行路径,介绍如何提高SQL性能的文章很多,这里不再赘述,本人来谈谈如何从 减少SQL回表次数 来提高查询性能,因为回表将导致扫描更多的数据块. 我们大家都知道,数据库表中数据存储都是以块为单位,称为数据块:表中每行数据都有唯一的地址标志ROWID. 举个例子: select a from test_db where b=5 A.假设b上没有索引 1.那么该条SQL将进行表扫描,扫描所有该表的数据块 2.从数据块中找到记录,并且进行过滤 可想而知,没有

#标记不参与计算的明细(跨平台的或is_end=2)#跨平台订单:暂不处理 说明:大表即order_list_wx,几十万,需要根据小表(order_list_zfb ,几万)来做更新,查出两个平台都有订单号(因为程序BUG所导致的). @Run.ExecuteSql("标记跨平台订单",@"update bi_data.order_list_wx a set is_end='2'where exists (select 1 from bi_data.order_list_z

如果我们直接用delete from语句来删除读写频繁的大表中的数据,很有可能会因为where的条件是全表扫描从而导致整个表被锁住了.如果该表是读写频繁的生产库那简直就是一场灾难,所有的线上读写请求都会因为表被锁而超时. 如果不想如此糟糕的情况发生,我们可以先分析一下导致表被锁住的原因.既然全表扫描会会导致锁表,那我们就先把删除操作分为查询和删除.然后再分批删除,如此就可以保证不会引发线上读写请求大规模超时.如果这样你还担心频繁的分批删除影响线上效率的话,还可以在每个批次加上一定的延时. /*

系统要求进行SQL优化,对效率比较低的SQL进行优化,使其运行效率更高,其中要求对SQL中的部分in/not in修改为exists/not exists 修改方法如下: in的SQL语句 SELECT id, category_id, htmlfile, title, convert(varchar(20),begintime,112) as pubtime FROM tab_oa_pub WHERE is_check=1 and category_id in (select id from

http://www.169it.com/article/3219955334.html     sql语句使用基本原则:1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引.2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id... sql语句使用基本原则: 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索

前言 SQL Server 2005开始支持表分区,这种技术允许所有的表分区都保存在同一台服务器上.每一个表分区都和在某个文件 组(filegroup)中的单个文件关联.同样的一个文件/文件组可以容纳多个分区表. 在这种设计架构下,数据库引擎能够判定查询过程中应该访问哪个分区,而不用扫描整个表.如果查询需要的数据行分散在多个分区中,SQL Server使用多个处理器对多个分区进 行并行查询.你可以为在创建表的时候就定义分区的索引. 对小索引的搜索或者扫描要比扫描整个表或者一张大表上的索引要快很多

前言 关于SQL Server基础系列尚未结束,还剩下最后一点内容未写,后面会继续.有园友询问我什么时候开始写SQL Server性能系列,估计还得等一段时间,最近工作也比较忙,但是会陆陆续续的更新SQL Server性能系列,本篇作为性能系列的基本引导,让大家尝尝鲜.在涉及到SQL Server性能优化时,我看到的有些文章就是一上来列出SQL Server的性能优化条例,根本没有弄清楚为什么这么做,当然也有可能是自己弄懂了,只是作为备忘录,但是到了我这里,我会遵循不仅仅是备忘录,还要让各位园友