对于SELECT * FROM TABLE这种方式，我想很多人都会这么去查询。WHY？一方面是因为系统的数据量级别还比较低，二来也图方便。但是随着项目的数据量疯长，系统的性能急速下降之后，优化的每一种方式都需要引起我们的重视。像查询这种方式来讲，如果不用检索出所有列的情况，尽量指定查询的列。这能有效减轻网络的负载和服务器资源的消耗。即使确实需要检索所有列，也不要使用SELECT *，因为这是一个非

如果DBMS 优化器认为检索范围过宽，那么它将放弃索引查找而使用全表扫描。下面是几种可能造成检索范围过宽的情况：使用IS NOT NULL或者不等于判断，可能造成优化器假设匹配的记录数太多。使用LIKE 运算符的时候，"a%"将会使用索引，而"a%c"和"%c"则会使用全表扫描，因为"a%c"和"%c"不能被有效的评估匹配的数量。

当 SQL 语句需要UNION 两个查询结果集合时，即使检索结果中不会有重复的记录，如果使用UNION这两个结果集同样会尝试进行合并，然后在输出最终结果前进行排序。因此，如果检索结果中不会有重复的记录的话，应该用UNION ALL替代UNION，这样效率就会因此得到提高。下面的语句2 就比语句1效率更加高。语句 1：复制代码SELECTACCT_NUM, BALANCE_AMT

在 WHERE 子句中，如果索引列是计算或者函数的一部分，DBMS 的优化器将不会使用索引而使用全表扫描。例如下面的SQL语句用于检索月薪的12倍大于两万五千元的员工：SELECT [TName],[FSalary] FROM T_EmployeeWHERE FSalary * 12 >25000;由于在大于号左边的是FSalary与12 的成绩表达式，这样DBMS 的优化

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

很多人会使用存储过程把SQL语句预先编译起来，以此来达到优化的目的。有的项目是根据用户的输入来动态执行SQL语句，不管何种方式，都使用参数化的方式来执行，这样不仅可以避免SQL注入漏洞攻击，最重要数据库会对这些参数化SQL执行预编译，这样第一次执行的时候DBMS会为这个SQL语句进行查询优化并且执行预编译，这样以后再执行这个SQL 的时候就直接使用预编译的结果，这样可以大大提高执行的速度。

大学读书时就听说过数据库里面的索引，一直没去深究过，也在无知无畏中进行了四年多的开发生涯，想来惭愧的很，今天有幸了解，顿感人生之阔然开朗一般。索引，不单是数据库里面才有，像我们写代码不也碰到数组也有索引嘛。索引就是已经按照某一种固定好的方式排序好内容，然后我们再去通过索引位置来定位到它。说到SQL SERVER的索引，有必要讲讲两个概念。分别是聚簇索引和非聚簇索引。1、聚簇索引：就是索引存储的

SELECT FirstName,LastName,Title INTO #MyOtherContactsFROM Person.Contact WHERE Suffix='Jr.'

对于SQL语句的执行，每次都要建立网络连接、进行权限校验、进行SQL语句的查询优化、发送执行结果，这个过程是非常耗时的，因此应该尽量避免过多的执行SQL语句，能够压缩到一句SQL执行的语句就不要用多条来执行。

T_Person 表的字符串类型字段FLevel 为人员的级别，在FAge 字段上建有索引。我们执行下面的SQL语句用于检索所有级别等于10的员工：SELECT FId,FAge,FNameFROM T_PersonWHERE FAge=10在这个SQL 语句中，将字符串类型字段FLevel 与数值10 进行比较，由于在大部分数据库中隐式转换类型中数值类型的优先级高于字符串