Server中，经常会用到Identity标识列，这种自增长的字段操作起来的确是比较方便。但它有时还会带来一些麻烦。 示例一 ：当表中被删除了某些数据的时候，自增长列的编号就不再是一个连线的数列。这种时候我们可以用以下方案来解决。 SET IDENTITY_INSERT [TABLE] [ON|OFF] 允许将显式值插入表的标识列中，当设置为ON时，这时可能在INSERT操作时手工指定插入到标识列中的编号，同时必须在操作完成后，将IDENTITY_INSERT还原成OFF，否则下次插入的时候必须指定编号，那不然就无法完成INSERT操作。 示例二：当表中的记录被全部删除，但此时标识列的值越来越大的时候，如果不加以重置，它还会无休止的增长。这个时候我们就要用到： DBCC CHECKIDENT（TABLE, [RESEED|NORESEED], [1]) 将把指定表的种子值强制重设为1。然而，你可能不想将种子重设为1，在这种情况下，你可以用你想用的种子值替代第三个参数。有时候你可能想知道当前的种子，而不是想重设种子,这时你就要用到NORESEED，而不用再去顾忌第三个参数。 “一网打尽”通用SQL数据库的查询语句 （1） 发布时间： 04:40 来源：赛迪网 作者：20933 通用SQL数据库的查询语句： （注释：本文中Transact-SQL查询只包括选择列表、FROM子句和WHERE子句。） 一、 简单查询 简单的Transact-SQL查询只包括选择列表、FROM子句和WHERE子句。它们分别说明所查询列、查询的表或视图、以及搜索条件等。 例如，下面语句显示testtable表中所有列的数据: SELECT * FROM testtable 2、选择部分列并指定它们的显示次序 查询结果集合中数据的排列顺序与选择列表中所指定的列名排列顺序相同。 例如: SELECT nickname,email FROM testtable 3、更改列标题 在选择列表中，可重新指定列标题。定义格式为: 列标题=列名 列名 列标题 如果指定的列标题不是标准的标识符格式时，应使用引号定界符，例如，下列语句使用汉字显示列标题: SELECT 昵称=nickname,电子邮件=email FROM testtable 4、删除重复行 SELECT语句中使用ALL或DISTINCT选项来显示表中符合条件的所有行或删除其中重复的数据行，默认为ALL。使用DISTINCT选项时，对于所有重复的数据行在SELECT返回的结果集合中只保留一行。 5、限制返回的行数 使用TOP n 百分号%:可匹配任意类型和长度的字符，如果是中文，请使用两个百分号即%%。 下划线_:匹配单个任意字符，它常用来限制表达式的字符长度。 selectstatement][…n] 其中selectstatement为待联合的SELECT查询语句。 ALL选项表示将所有行合并到结果集合中。不指定该项时，被联合查询结果集合中的重复行将只保留一行。 联合查询时，查询结果的列标题为第一个查询语句的列标题。因此，要定义列标题必须在第一个查询语句中定义。要对联合查询结果排序时，也必须使用第一查询语句中的列名、列标题或者列序号。 在使用UNION 运算符时，应保证每个联合查询语句的选择列表中有相同数量的表达式，并且每个查询选择表达式应具有相同的数据类型，或是可以自动将它们转换为相同的数据类型。在自动转换时，对于数值类型，系统将低精度的数据类型转换为高精度的数据类型。 在包括多个查询的UNION语句中，其执行顺序是自左至右，使用括号可以改变这一执行顺序。例如: 查询1 UNION (查询2 UNION 查询3) 三、连接查询 通过连接运算符可以实现多个表查询。连接是关系数据库模型的主要特点，也是它区别于其它类型数据库管理系统的一个标志。 在关系数据库管理系统中，表建立时各数据之间的关系不必确定，常把一个实体的所有信息存放在一个表中。当检索数据时，通过连接操作查询出存放在多个表中的不同实体的信息。连接操作给用户带来很大的灵活性，他们可以在任何时候增加新的数据类型。为不同实体创建新的表，尔后通过连接进行查询。 连接可以在SELECT 其中join_table指出参与连接操作的表名，连接可以对同一个表操作，也可以对多表操作，对同一个表操作的连接又称做自连接。 join_type 指出连接类型，可分为三种:内连接、外连接和交叉连接。内连接(INNER JOIN)使用比较运算符进行表间某(些)列数据的比较操作，并列出这些表中与连接条件相匹配的数据行。根据所使用的比较方式不同，内连接又分为等值连接、自然连接和不等连接三种。外连接分为左外连接(LEFT OUTER JOIN或LEFT JOIN)、右外连接(RIGHT OUTER JOIN或RIGHT JOIN)和全外连接(FULL OUTER JOIN或FULL JOIN)三种。与内连接不同的是，外连接不只列出与连接条件相匹配的行，而是列出左表(左外连接时)、右表(右外连接时)或两个表(全外连接时)中所有符合搜索条件的数据行。 交叉连接(CROSS JOIN)没有WHERE 子句，它返回连接表中所有数据行的笛卡尔积，其结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。 连接操作中的ON DATALENGTH(p1.pr_info)=DATALENGTH(p2.pr_info) (一)内连接 内连接查询操作列出与连接条件匹配的数据行，它使用比较运算符比较被连接列的列值。内连接分三种: 1、等值连接:在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结果中列出被连接表中的所有列，包括其中的重复列。 2、不等连接: 在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括> 、> =、 <=、 <、!> 、! <和> <> 。 3、自然连接:在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选择列表指出查询结果集合中所包括的列，并删除连接表中的重复列。 条件)和连接条件的行。而采用外连接时，它返回到查询结果集合中的不仅包含符合连接条件的行，而且还包括左表(左外连接时)、右表(右外连接时)或两个边接表(全外连接)中的所有数据行。如下面使用左外连接将论坛内容和作者信息连接起来: SELECT a.*,b.* FROM luntan LEFT JOIN usertable as b ON a.username=b.username 子句，它返回被连接的两个表所有数据行的笛卡尔积，返回到结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。例，titles表中有6类图书，而publishers表中有8家出版社，则下列交叉连接检索到的记录数将等。 于6*8=48行。 SELECT type,pub_name FROM titles CROSS JOIN publishers 三种数据库利用SQL语句进行高效果分页 发布时间： 04:50 来源：赛迪网 作者：10687 在程序的开发过程中，处理分页是大家接触比较频繁的事件，因为现在软件基本上都是与数据库进行挂钓的。但效率又是我们所追求的，如果是像原来那样把所有满足条件的记录全部都选择出来，再去进行分页处理，那么就会多多的浪费掉许多的系统处理时间。为了能够把效率提高，所以现在我们就只选择我们需要的数据，减少数据库的处理时间，以下就是常用SQL分页处理： 1、SQL Server、Access数据库 作者：Liulian 很多人对子查询(subqueries)的使用都感到很迷惑，尤其对于嵌套子查询(即子查询中包含一个子查询)。现在，就让我们追本溯源地探究这个问题。 有两种子查询类型：标准和相关。标准子查询执行一次，结果反馈给父查询。相关子查询每行执行一次，由父查询找回。在本文中，我将重点讨论嵌套子查询(nested subqueries)(我将在以后介绍相关子查询)。 Server中，你从内压式(outside-in)写程序，但从外压式(inside-out)开始考虑非常有帮助，即可以一次解决需要的一个语句。 这个例子揭示了有关SQL Server的几个绝妙事情。你可以发现，可以用IN()参数替代SELECT 语句。在本例中，有两次应用，因此创建了一个嵌套子查询。 我是标准化(normalization)的发烧友，尽管我不接受其荒谬的长度。由于标准化具有各种查询而增加了复杂性。在这些情况下子查询就显得非常有用，嵌套子查询甚至更加有用。 当你需要的问题分散于很多表格中时，你必须再次将它们拼在一起，这时你可能发现嵌套子程序就很有用。 使用SQL视图查出所有的数据库字典 发布时间： 09:15 来源：赛迪网 作者：20936 在对跨多个表格的数据进行组合时，有时很难搞清楚要使用哪一个SQL句法。我将在这里对将多个表格中的查询合并至单一声明中的常用方式进行阐述。 在这篇文章中的样本查询符合SQL92 ISO标准。不是所有的数据库生产商都遵循这项标准，而且很多厂商采取的提升措施会带来一些意料不到的后果。如果你不确定你的数据库是不是支持这些标准，你可以参看生产厂商的有关资料。 SELECT 一个简单的SELECT声明就是查询多个表格的最基本的方式。你可以在FROM子句中调用多个表格来组合来自多个表格的结果。这里是一个它如何工作的实例： 这个实例中，我使用点号(table1.column1)来指定专栏来自哪一个表格。如果所涉及的专栏只在一个参考的表格中出现，你就不需要加入完整的名称，但是加入完整名称会对可读性起到帮助。 在FROM子句中表格之间由逗号来分隔，你可以加入所需的任意多的表格，尽管一些数据库有一个在引入正式的JOIN声明之前他们可以有效地处理的内容这方面的限制，这个将在下面谈到。 这个句法是一个简单的INNER JOIN。一些数据库将它看成与一个外部的JOIN是等同的。WHERE子句告知数据库哪一个区域要做关联，而且它返回结果时，就像列出的表格在给定的条件下组合成一个单独的表格一样。值得注意的是，你的比较条件并不需要与你作为结果组返回的专栏相同。在上面的例子中，table1.column1和table2.column1用来组合表格，但是返回的却是table2.column2。 你可以在WHERE子句中使用AND关键字来将这个功能扩展至多于两个的表格。你还可以使用这样的表格组合来限制你的结果而不用实际地从每个表格返回专栏。在下面的例子中，table3与table1匹配，但是我没有从table3返回任何东西来显示。我只是确保来自table1的有关专栏存在于table3之中。注意此例中table3需要在FROM子句中被引用。 以下为引用的内容： SELECT 然而，要注意的是，这个查询多个表格的方式是一个暗指的JOIN。你的数据库可能对事物进行不同的处理，这取决于它所使用的优化引擎。而且，忽略对与WHERE子句的相关特性的定义将会给你带来不愿看到的结果，例如从余下的查询中返回与每一个可能的结果相关的专栏的rogue域，就像在CROSS JOIN之中一样。 如果你习惯于你的数据库处理这种类型的声明的方式，且你只对两个或是少数几个表格进行组合，一个简单的SELECT声明就可以达到目的。 JOIN JOIN的工作方式与SELECT声明是相同的，它从不同的表格中返回一个带有专栏的结果组。在暗含的JOIN之上使用外部JOIN的优势是对你的结果组的更好的控制，而且还可能在涉及很多个表格的情况下提升性能表现。 JOIN的类型有几种：LEFT，RIGHT，FULL OUTER，INNER和CROSS。你所使用的类型是由你想要看到的结果所决定的。例如，使用LEFT OUTER JOIN将会从列出的第一个表格中返回所有有关的行，而同时如果没有信息与第一个表格相关的话将潜在地从所列出的第二个表格中加入行。 在这里INNER JOIN和暗含的JOIN是不同的，INNER 子查询，或叫子选择声明，是在一个查询中将结果组作为资源使用的一个途径。他经常被用来对结果进行限制或定义，而不是运行多个查询或操纵应用软件之中的数据。有了子查询，你可以参考表格来决定数据的内含，或是在一些情况下，返回一个专栏，而这个专栏是一个子选择的结果。 下面的例子中使用了两个表格。一个表格中包含了我想要返回的数据，而另一个表格则给出一个比较点来确定什么数据是我确实感兴趣的。 子查询很重要的一个方面就是性能表现。便利性是有代价的，它取决于你所使用的表格和声明的大小，数量和复杂性，还有你可能会允许你的应用软件做处理工作。每一个查询在被主查询作为资源使用之前，都将被完整地单独处理。如果可能的话，创造性地使用JOIN声明可以以较少的滞后时间提供出相同的信息。 （责任编辑：卢兆林） 深入讲解SQL Union和Union All的使用方法 发布时间： 04:41 来源：赛迪网 作者：李思 【赛迪网－IT技术报道】UNION指令的目的是将两个SQL语句的结果合并起来。从这个角度来看， 我们会产生这样的感觉，UNION跟JOIN似乎有些许类似，因为这两个指令都可以由多个表格中撷取资料。 UNION的一个限制是两个 SQL 语句所产生的栏位需要是同样的资料种类。另外，当我们用 length('2D') - rownum) data1 from dual connect by rownum <= length('2D')) 注释： 对其它进制可以根据例子将power的底数改成相应的进制就可以了。 本文只是一个例子，大家可以把它封装成一个通用函数进行实用。 大家在试的时候将里面相应的其它进制的数值换成自己的数据就可以了（有多处）。 实例讲解如何才能让你的SQL运行得更快 （1） 发布时间： 04:52 来源：赛迪网 作者：10633 很多人在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。 笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。 在对它们进行适当的优化后，其运行速度有了明显地提高！ 下面我将从这三个方面分别进行总结： 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均表示为（< 1秒）。---- 测试环境: 主机：HP LH II---- 主频：330MHZ---- 分析：在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。 3.在place，date，amount上的组合索引 select count(*) from record where date > '' and date < 分析：这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。 4.在date，place，amount上的组合索引 select count(*) from record where date > '' 1秒） 分析：这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。 5.总结： 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。 一般来说： ①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考虑建立群集索引； ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引； ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。 二、不充份的连接条件： 在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O 可见，只有充份的连接条件，真正的最佳方案才会被执行。 总结： 1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。 2.查看执行方案的方法-- 用set ('0','1')转化为id_no ='0' or id_no='1'来执行。 我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引； 但实际上（根据showplan）,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no上索引，并且完成时间还要受tempdb数据库性能的影响。 实践证明，表的行数越多，工作表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分开： @d=convert(char(10),@c)print @d 直接算出结果，执行时间同上面一样快！ 总结： 大家可以看到，优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。 1.任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。 2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。 3.要善于使用存储过程，它使SQL变得更加灵活和高效。 从以上这些例子可以看出，SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。 利用"SQL"语句自动生成序号的两种方式 发布时间： 04:55 问：为什么SQL Server不允许在视图定义使用ORDER BY子句？ 答： SQL Server之所以不允许在视图定义中使用ORDER BY子句是为了遵守ANSI SQL-92标准。因为对该标准的原理分析需要对结构化查询语言（SQL）的底层结构和它所基于的数学理论进行讨论，我们不能在这里对它进行充分的解释。但是，如果你需要在视图中指定ORDER BY子句，可以考虑使用以下方法： 出错原因：用户增加了一个条件member.site=test,造成连接的顺序变化了，原来的驱动表是uidTable(最多1024条记录），现在变成了member表做驱动(600W条）。所以这条语句变的巨慢。 但是既然是外连接，为什么连接的顺序会改变呢？因为外连接的连接顺序不是由COST决定的，而是由连接的条件决定的。发现执行计划如下： 上面两种方法,哪种方法效率高? 答： 这个一般是exists快, 当然, 具体还要看你后面的子查询的条件, 是否会引用外层查询中的对象的列. exists检查到有值就返回, 而且不返回结果集, count需要统计出所有满足条件的, 再返回一个结果集, 所以一般情况下exists快. 问题5： (5)NULLIF的使用----->同理它的反函数ISNULL的使用 update tb 通过两个例子讲解PIVOT/UNPIVOT的用法 发布时间： 04:58 来源：赛迪网 作者：ChenJaYi 【赛迪网－IT技术报道】使用过SQL Server 2000的人都知道，要想实现行列转换,必须综合利用聚合函数和动态SQL，具体实现起来需要一定的技巧，而在SQL Server 发布时间： 04:51 来源：赛迪网 作者：10633 操作符优化 ◆IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。 但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 推荐方案：在业务密集的SQL当中尽量不采用IN操作符。 ◆NOT IN操作符 此操作是强列推荐不使用的，因为它不能应用表的索引。 推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替 ◆<> 操作符（不等于） 不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 推荐方案：用其它相同功能的操作运算代替，如 a<>0 改为 a>0 or a<0 a<>’’ 改为 a>’’ IS NULL 或IS NOT NULL操作（判断字段是否为空） 判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。 推荐方案： 用其它相同功能的操作运算代替，如 a is not null 改为 a>0 或a>’’等。 不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。 建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象） ◆> 及 < 操作符（大于或小于操作符） 　　　大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。 ◆LIKE操作符 LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。 ◆UNION操作符 UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如： select * from gc_dfys union select * from ls_jg_dfys 这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。 推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。 select * from gc_dfys union 都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同则ORACLE只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，ORACLE也可以准确统计SQL的执行频率。 ◆WHERE后面的条件顺序影响 WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如 Select * from '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。 ◆查询表顺序的影响 在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。（注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接） ◆SQL语句索引的利用 对操作符的优化（见上节） 对条件字段的一些优化 条件内包括了多个本表的字段运算时不能进行索引，如： ys_df>cx_df，无法进行优化 qc_bh||kh_bh=’’， 优化处理：qc_bh=’5400’ and kh_bh=’250000’ 应用ORACLE的HINT（提示）处理 提示处理是在ORACLE产生的SQL分析执行路径不满意的情况下要用到的。它可以对SQL进行以下方面的提示 ◆目标方面的提示： INDEX（TABLE INDEX）（使用提示的表索引进行查询） 其它高级提示（如并行处理等等） 用SQL语句删除重复记录的四种好方法 发布时间： 04:44 来源：赛迪网 作者：林夕 问题：如何把具有相同字段的纪录删除，只留下一条。 例如：表test里有id,name字段,如果有name相同的记录只留下一条，其余的删除。name的内容不定，相同的记录数不定。 注释：此处delete原表，再加入不重复的值。大家也可以通过join只delete原表中重复的值。 不要在SQL Server中盲目地追求一句处理 （1） 发布时间： 05:10 来源：赛迪网 作者：shuijing 在日常的学习和工作中，我们可以经常发现在处理SQL Server的时，很多人都会有一句出结果的习惯，但值得注意的是，不恰当的合并处理语句，往往会产生负面的性能，本篇针对使用 UNION ALL 代替 IF 语句的合并处理做出一个简单的事例，用来说明这种方法会所带来的负面结果。 示例： 表A和表B，这两个表结构一致，为不同的业务服务，现在写一个存储过程，存储过程接受一个参数，当参数为0时，查询表A，参数为1时，查询表B。 1:一般处理方法: 从语句的简捷性来看，方法b具有技巧性，它们两者之间，究竟那一个更好呢？你可能会从性能上来评估，以决定到底用那一种。单纯从语句上来看，似乎两者的效率差不多，下面通过数据测试来反映结果似乎和想像的一样。 建立测试环境：（注，此测试环境主要是为几个主题服务，因此结构看起来稍有差异） USE tempdb GO SET NOCOUNT ON 虽然在性能上，两者没有什么差异，但另一个问题也许你从来没有考虑过，那就是对表的访问的问题，在方法A中，肯定只会访问到一个表；而在方法B中，情况还是如此吗？答案是否定的，方法B始终会扫描两个表。而这样的潜台词是，即使在我的查询中，只会用到A表，但如果B表被下了锁的话，整个查询就会被阻塞，而方法A不会。 为了证明这个问题，我们再做下面的测试 BLOCK 的测试—为表A加锁： (查询窗口A) sp_who2，查看当前的BLOCK状况来确定查询窗口C的查询是否被查询窗口A的查询BLOCK住。 最后结论： 不要使用查询方法B，它看起来很不错，实际的结果即则是会增加被BLOCK的机会。 用人工智能技术自动对SQL语句进行重写 （1） 发布时间： 04:56 来源：赛迪网 作者：Lynn 【赛迪网－IT技术报道】SQL语句的优化是将性能低下的SQL语句转换成目的相同的性能优异的SQL语句。 人工智能自动SQL优化就是使用人工智能技术，自动对SQL语句进行重写，从而找到性能最好的等效SQL语句。 数据库性能的优化 一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。 应用程序的优化 应用程序的优化通常可分为两个方面：源代码和SQL语句。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高，而对数据库系统性能的提升收效有限。 为什么要优化SQL语句 . SQL语句是对数据库进行操作的惟一途径，对数据库系统的性能起着决定性的作用。 . SQL语句消耗了70%至90%的数据库资源。 . SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑。 . SQL语句有不同的写法，在性能上的差异非常大。 . SQL语句易学，但难精通。 优化SQL语句的传统方法是通过手工重写来对SQL语句进行优化。DBA或资深程序员通过对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较，以试图找到性能较佳的SQL语句。这种传统上的作法无法找出SQL语句的所有可能写法，且依赖于人的经验，非常耗费时间。 SQL优化技术的发展历程 第一代SQL优化工具是执行计划分析工具。这类工具针对输入的SQL语句，从数据库提取执行计划，并解释执行计划中关键字的含义。 第二代SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析，来产生是否要增加索引的建议。 第三代SQL优化工具不仅分析输入SQL语句的执行计划，还对输入的SQL语句本身进行语法分析，经过分析产生写法上的改进建议。 人工智能自动SQL优化 DB2数据库平台。该产品针对数据库应用的开发和维护阶段提供的模块有：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块SQL 语法优化器的工作原理为：①输入一条源SQL语句；②“人工智能反馈式搜索引擎”对输入的SQL语句，结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出；③产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满；④对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句；⑤对得到的SQL语句进行批量测试，找出性能最好的SQL语句。 接下来，我们可以对自动重写产生的136条SQL语句进行批运行测试，以选出性能最佳的等效SQL语句。按下“批运行” 按钮，在“终止条件” 页选择“最佳运行时间SQL语句”，按“确定”。 经过几分钟的测试运行后，我们可以发现SQL124的运行时间和反应时间最短。运行速度约有22.75倍的提升(源SQL语句运行时间为2.73秒，SQL124运行时间为0.12秒)。现在我们就可以把SQL124放入源代码中，结束一条SQL语句的优化工作了。 “边做边学式训练”提升SQL开发水平 LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的“SQL比较器”可以标明源SQL和待选SQL间的不同之处。 以上面优化的结果为例，为了查看源SQL语句和SQL124在写法上有什么不同，我们可以按下“比较器” 按钮，对SQL124和源SQL语句进行比较。“SQL 比较器”将SQL124相对于源SQL语句的不同之处以蓝颜色表示了出来。如果选择“双向比较”复选框，“SQL 比较器”可以将两条SQL语句的不同之处以蓝色表示。当然，我们也可以从源语句和重写后的SQL 语句中任选两条进行比较。 从比较的结果可以看到，重写后的SQL124把第一个Exists改写成了In；在字段DPT_ID上进行了合并空字符串的操作，以诱导数据库先执行子查询中的 如果觉得对写法的改变难以理解，还可以点中“执行计划”复选框，通过比较两条SQL语句的执行计划的不同，来了解其中的差异。在查看执行计划过程中，如果有什么不明白的地方，可以点中“SQL信息按钮”，再点击执行计划看不明白的地方，LECCO SQL Expert的上下文敏感帮助系统将提供执行计划该处的解释。 在“SQL比较器”中，选中“统计信息”复选框后，可得到详细的两条SQL语句运行时的统计信息比较，这对于学习不同的SQL写法对数据库资源的消耗很有帮助。 LECCO SQL Expert优化模块的特点 LECCO SQL Expert优化模块的特点主要表现为：自动优化SQL语句；以独家的人工智能知识库“反馈式搜索引擎”来重写性能优异的SQL语句；找出所有等效的SQL语句及可能的执行计划；保证产生相同的结果；先进的SQL语法分析器能处理最复杂的SQL语句；可以重写SELECT、SELECT INTO、UPDATE、INSERT和DELETE语句；通过测试运行，为应用程序和数据库自动找到性能最好的SQL语句；提供微秒级的计时，能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句；为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能；提供上下文敏感的执行计划帮助系统和SQL运行状态帮助；不是猜测或建议，而是独一无二的SQL重写解决方案。 写出专家级的SQL语句 LECCO SQL Expert的出现，使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮用户找到最好性能的写法。LECCO SQL Expert不仅能在很短的时间内找到所有可能的优化方案，而且能够通过实际测试，确定最有效的优化方案。同以往的数据库优化手段相比较，LECCO SQL Expert将数据库优化技术带到了一个崭新的技术高度，依赖人的经验、耗费大量时间、受人的思维束缚的数据库优化手段已经被高效、省时且准确的自动优化软件所取代了。通过内建的“LECCO小助手”的帮助，即使是SQL的开发新手，也能快速且简单地写出专家级的SQL语句。