sql优化培训

在SQL查询中，为了提高查询的效率，我们常常采取一些措施对查询语句进行SQL性能优化。本文我们总结了一些优化措施，接下来我们就一一介绍。1.查询的模糊匹配尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用。解决办法:其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联。2.索引问题在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定义索引，而开发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多。这时缺少索引，对性能的影响便会越来越大了。法则：不要在建立的索引的数据列上进行下列操作:避免对索引字段进行计算操作避免在索引字段上使用not，<>，!=避免在索引列上使用IS NULL和IS NOT NULL避免在索引列上出现数据类型转换避免在索引字段上使用函数避免建立索引的列中使用空值3.复杂操作部分UPDATE、SELECT 语句 写得很复杂（经常嵌套多级子查询）——可以考虑适当拆成几步，先生成一些临时数据表，再进行关联操作。同一个表的修改在一个过程里出现好几十次，如：update table1 set col1=... where col2=...; update table1 set col1=... where col2=... ... 这类脚本其实可以很简单就整合在一个UPDATE语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）5.在可以使用UNION ALL的语句里，使用了UNIONUNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用 UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）。6.在WHERE 语句中，尽量避免对索引字段进行计算操作这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了。9月份在对XX系统做性能分析时发现，有大量的后台程序存在类似用法，如：where trunc(create_date)=trunc(:date1)，虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是where create_date>=trunc(:date1) and create_date< pre=""><>或者是where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)。注意：因between 的范围是个闭区间（greater than or equal to low value and less than or equal to high value.），故严格意义上应该再减去一个趋于0的小数，这里暂且设置成减去1秒（1/(24*60*60)），如果不要求这么精确的话，可以略掉这步。7.对Where 语句的法则 避免在WHERE子句中使用in，not in，or 或者having。可以使用 exist 和not exist代替in和not in。可以使用表链接代替 exist。Having可以用where代替，如果无法代替可以分两步处理。例子SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN (SELECT CUSTOMER_NAME FROM CUSTOMER) 优化SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist (SELECT CUSTOMER_NAME FROM CUSTOMER) 不要以字符格式声明数字，要以数字格式声明字符值。（日期同样）否则会使索引无效，产生全表扫描。例子使用：SELECT , FROM emp WHERE = 7369;--不要使用：SELECT , FROM emp WHERE = '7369'8.对Select语句的法则在应用程序、包和过程中限制使用select * from table这种方式。看下面例子--使用SELECT empno,ename,category FROM emp WHERE empno = '7369'--而不要使用SELECT * FROM emp WHERE empno = '7369'9. 排序避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序。10.临时表慎重使用临时表可以极大的提高系统性能。关于SQL性能优化的知识就介绍到这里了，希望本次的介绍能够带给您一些收获，谢谢！

（1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：

ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写

在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的

情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询

, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其

他表所引用的表.

（2） WHERE子句中的连接顺序．：

ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必

须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE

子句的末尾.

（3） SELECT子句中避免使用‘ * ‘：

ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过

查询数据字典完成的, 这意味着将耗费更多的时间

（4）减少访问数据库的次数：

ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变

量 , 读数据块等；

（5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加

每次数据库访问的检索数据量 ,建议值为200

（6）使用DECODE函数来减少处理时间：

使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.

（7）整合简单,无关联的数据库访问：

如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使

它们之间没有关系)

（8）删除重复记录：

最高效的删除重复记录方法 ( 因为使用了ROWID)例子：

DELETE FROM EMP E WHERE > (SELECT MIN()

FROM EMP X WHERE = );

（9）用TRUNCATE替代DELETE：

当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存

放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前

的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回

滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的

资源被调用,执行时间也会很短. (译者按: TRUNCATE只在删除全表适

用,TRUNCATE是DDL不是DML)

（10）尽量多使用COMMIT：

只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也

会因为COMMIT所释放的资源而减少:

COMMIT所释放的资源:

a. 回滚段上用于恢复数据的信息.

b. 被程序语句获得的锁

c. redo log buffer 中的空间

d. ORACLE为管理上述3种资源中的内部花费

（11）用Where子句替换HAVING子句：

避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行

过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,

那就能减少这方面的开销. (非oracle中)on、where、having这三个都可以加条

件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条

件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该

速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在

两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。

在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们

的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度

上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不

确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而

having就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多

表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，

把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由

having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条

件应该在什么时候起作用，然后再决定放在那里

（12）减少对表的查询：

在含有子查询的SQL语句中,要特别注意减少对表的查询.例子：

SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT

TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)

（13）通过内部函数提高SQL效率.：

复杂的SQL往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法

在实际工作中是非常有意义的

（14）使用表的别名(Alias)：

当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column

上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误.

（15）用EXISTS替代IN、用NOT EXISTS替代NOT IN：

在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联

接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率. 在子查

询中,NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下,NOT IN都是

最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN

,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.

例子：

（高效）SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND EXISTS (SELECT

‘X' FROM DEPT WHERE = AND LOC = ‘MELB')

(低效)SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT

DEPTNO FROM DEPT WHERE LOC = ‘MELB')

（16）识别'低效执行'的SQL语句：

虽然目前各种关于SQL优化的图形化工具层出不穷,但是写出自己的SQL工具

来解决问题始终是一个最好的方法：

SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-

DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2)

Reads_per_run,

SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND

(BUFFER_GETS-DISK_READS)/BUFFER_GETS < ORDER BY 4 DESC;

（17）用索引提高效率：

索引是表的一个概念部分,用来提高检索数据的效率，ORACLE使用了一个复

杂的自平衡B-tree结构. 通常,通过索引查询数据比全表扫描要快. 当ORACLE找

出执行查询和Update语句的最佳路径时, ORACLE优化器将使用索引. 同样在联结

多个表时使用索引也可以提高效率. 另一个使用索引的好处是,它提供了主键

(primary key)的唯一性验证.。那些LONG或LONG RAW数据类型, 你可以索引几乎

所有的列. 通常, 在大型表中使用索引特别有效. 当然,你也会发现, 在扫描小

表时,使用索引同样能提高效率. 虽然使用索引能得到查询效率的提高,但是我们

也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在

表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的INSERT

, DELETE , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存

储空间和处理,那些不必要的索引反而会使查询反应时间变慢.。定期的重构索引

是有必要的.：

ALTER INDEX REBUILD

（18）用EXISTS替换DISTINCT：

当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在

SELECT子句中使用DISTINCT. 一般可以考虑用EXIST替换, EXISTS 使查询更为迅

速,因为RDBMS核心模块将在子查询的条件一旦满足后,立刻返回结果. 例子：

(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E

WHERE = (高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT

D WHERE EXISTS ( SELECT ‘X' FROM EMP E WHERE = );

（19） sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行

（20）在java代码中尽量少用连接符“＋”连接字符串！

在进行软件开发过程中，数据库的使用是非常重要的，但是数据库有很多种，不同数据库的使用方法是不同的。进行软件开发过程中，至少需要掌握一种数据库的使用方法。SQL数据库语法简单、操作方便和高效，是很多人最优的选择，但是SQL语句会受到不同数据库功能的影响，在计算时间和语言的效率上面需要进行优化，根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。一、适当的索引索引基本上是一种数据结构，有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库，但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引，处理速度会变得非常慢。二、仅索引相关数据指定需要检索数据的精度。使用命令*和LIMIT代替SELECT*。调整数据库时，必须使用所需的数据集而不是整个数据集，尤其是当数据源非常大时，指定所需的数据集，能够节省大部分时间。三、根据需求使用或避免临时表如果代码可以用简单的方式编写，那么永远不要使临时表变得复杂。当然，如果数据具有需要多个查询的特定程序，北大青鸟建议在这种情况下，使用临时表。临时表通常由子查询交替。四、避免编码循环避免编码循环是非常重要的，因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环，并且济南北大青鸟发现WHERE命令能够确保存储的数据不被更新，这样能够方便在找到匹配和预先存在的数据时被找到。

SQL优化

执行计划,表关联查询顺序,优化策略与思路

下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：

1.连接

客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求

将请求转发到‘连接进/线程模块’

调用‘用户模块’来进行授权检查

通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求

2.处理

先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回

上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树

接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树

再转交给对应的模块处理

如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划

模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限

有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件

根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理

上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中

3.结果

请求完成后，将结果集返回给‘连接进/线程模块’

返回的也可以是相应的状态标识，如成功或失败等

‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接

接下来再走一步，让我们看看一条SQL语句的前世今生。

首先看一下示例语句

示例语句

执行顺序

SQL解析

1. FROM

当涉及多个表的时候，左边表的输出会作为右边表的输入，之后会生成一个虚拟表VT1。

(1-J1)笛卡尔积

计算两个相关联表的笛卡尔积(CROSS JOIN) ，生成虚拟表VT1-J1。

两次全表扫描

哈希索引,查找复杂度都是 O(1) 。

2. WHERE

对VT1过程中生成的临时表进行过滤，满足WHERE子句的列被插入到VT2表中。

注意：

此时因为分组，不能使用聚合运算；也不能使用SELECT中创建的别名；

与ON的区别：

如果有外部列，ON针对过滤的是关联表，主表（保留表）会返回所有的列；

如果没有添加外部列，两者的效果是一样的；

应用：

对主表的过滤应该放在WHERE；

对于关联表，先条件查询后连接则用ON，先连接后条件查询则用WHERE；

hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次

应用场景:一个大表一个小表/表上没有索引/返回结果集比较大

3. GROUP BY

这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。

注意：

其后处理过程的语句，如SELECT,HAVING，所用到的列必须包含在GROUP BY中，对于没有出现的，得用聚合函数；

原因：

GROUP BY改变了对表的引用，将其转换为新的引用方式，能够对其进行下一级逻辑操作的列会减少；

原作者的理解是：

根据分组字段，将具有相同分组字段的记录归并成一条记录，因为每一个分组只能返回一条记录，除非是被过滤掉了，而不在分组字段里面的字段可能会有多个值，多个值是无法放进一条记录的，所以必须通过聚合函数将这些具有多值的列转换成单值；

GROUP BY 重新聚合查询

4. HAVING

这个子句对VT3表中的不同的组进行过滤，只作用于分组后的数据，满足HAVING条件的子句被加入到VT4表中。

LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。

注意：

offset和rows的正负带来的影响；

当偏移量很大时效率是很低的，可以这么做：

采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取N行结果集

采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，然后直接关联查询获得最终结果

当前未用到索引,

三次full scan , table1 AS a / table2 AS b / GROUP BY

尽量少做重复的工作

控制同一语句的多次执/减少多次的数据转换/

杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销

关于临时表和表变量的选择

临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以建议，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。

子查询的用法

相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入

NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法

如果保证子查询没有重复 ，IN、EXISTS的相关子查询可以用INNER JOIN 代替

IN``的相关子查询用EXISTS代替

不要用 COUNT (*)的子查询判断是否存在记录，最好用 LEFT` `JOIN 或者EXISTS，比如有人写这样的语句：

建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，

不要对索引字段进行运算，而要想办法做变换

不要对索引字段进行格式转换

不要对索引字段使用函数

不要对索引字段进行多字段连接

join关联查询的计算是很复杂的，特别是数据量比较大的情况下，实际情况还是拆解较快的

Join拆解的核心就是利用In关键字

要么用空间换时间，要么用时间换空间

多表连接的连接条件对索引的选择有着重要的意义，所以我们在写连接条件条件的时候需要特别注意。

A、多表连接的时候，连接条件必须写全，宁可重复，不要缺漏。

B、连接条件尽量使用聚集索引

C、注意ON、WHERE和HAVING部分条件的区别

ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比 HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了

考虑联接优先顺序：

(1)INNER JOIN

(2)LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)

(3)CROSS JOIN

索引并不适用于所有情况：a.少量数据；b.频繁进行改动的字段，不适合做索引；c.很少使用的字段，不需要加索引

索引会提高数据查询效率，但是会降低“增、删、改”的效率。当不使用索引的时候，我们进行数据的增删改，只需要操作源表即可，但是当我们添加索引后，不仅需要修改源表，也需要再次修改索引，很麻烦。

先执行顺序, 是否走索引, 有无类型转换

18000 字的SQL优化大全

步步深入：MySQL架构总览->查询执行流程->SQL解析顺序

MySQL索引总结（4）——btree与hash区别

1、模糊查询like。

使用like进行模糊查询时应该特别注意，这个很基本，基本上大家都知道。

select * from contact where username like ‘%yue%’

关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%。

2、where条件查询

尽量避免使用in,not in,having,可以使用 exist 和not exist代替 in和not in。不要以字符格式声明数字，要以数字格式声明字符值。

3、前面提到的from子句中有多个表进行关联查询时

在from子句中包含多个表的情况下，选择记录条数最少的表作为基础表，在某种程度上将会极大的提高其性能。如果有3个以上的表，则选择交叉表作为基础表

4、select *查询

尽量不要使用

select * from tablename

取而代之的则是：

select columnname1,columnname2 from tablename

5、排序操作

避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序。

6、索引表操作

对于此处，个人还没有弄明白，首先对于索引还不明白，那么性能优化更谈不上了。反正很多大牛都是操作索引表，需要特别注意。以后明白了再补充吧。

...

7、LEFT JOIN 和 inner join的区别，是否真的需要left join，否则选用inner join 来减少不必要的数据返回。

个人因为编程习惯问题，总喜欢写left join，看来以后要用大脑思考思考了。

同时，SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误。

8、统一规范sql语句

编写规范的sql语句，这一点是最重要的一点，不管对于系统还是个人来说，都是相当的重要。

使用like进行模糊查询时应该特别注意

select * from contact where username like ‘%yue%’

关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%。

尽量避免使用in,not in,having,可以使用 exist 和not exist代替 in和not in。不要以字符格式声明数字，要以数字格式声明字符值。

索引

加索引，本地模拟现场的业务场景，插入了大量的测试数据，在sql的where条件查询字段下加了索引，查询时间进入到秒级，完全满足项目要求。现场提供的视图，而且视图的厂家没有人维护了，不可能创建其它东西的，所以虽然索引有效但是无法使用。

参数

现场系统可以通过配置参数来对业务进行调整，执行的sql语句中加入了@参数Name=@Name or @Name = ''，上网经过搜索，发现参数不会对sql执行造成影响，但是如果你的where条件中的@参数正好加入了索引，那么影响就相当显著了。加入强制执行索引：

with(index(IX_Name))，效率有显示提升，奈何现场的视图已无参加维护。

Join

查询数据源采用了left join联表查询，问题来了，主表2w多行的数据，副表也是3w多行的数据，比较奇葩的使用了两个视图联表查询，还是那句没有厂家维护。联表查询n*m，那么减少基础表的记录数目可以有效的提高效率。那么把条件搜索放入到基础表先进性过滤，然后再进行联合查询。

select top 500 * from(select  * from  [dbo].[table1] where (ss between @a1 and @a2）) aLEFT JOIN  dbo.[table2] ON = dbo.[table2].n

结构化查询语言(Structured Query Language)简称SQL(发音：/ˈes kjuː ˈel/ "S-Q-L")，是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统；同时也是数据库脚本文件的扩展名。

结构化查询语言是高级的非过程化编程语言，允许用户在高层数据结构上工作。它不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式，所以具有完全不同底层结构的不同数据库系统, 可以使用相同的结构化查询语言作为数据输入与管理的接口。结构化查询语言语句可以嵌套，这使它具有极大的灵活性和强大的功能。

1986年10月，美国国家标准协会对SQL进行规范后，以此作为关系式数据库管理系统的标准语言（ANSI X3. 135-1986），1987年得到国际标准组织的支持下成为国际标准。不过各种通行的数据库系统在其实践过程中都对SQL规范作了某些编改和扩充。所以，实际上不同数据库系统之间的SQL不能完全相互通用。

参考资料：

sql优化-百度百科