1. 쿼리 최적화는, 첫째 경우 주문에 포함 된 열을 기준으로 색인을 고려해야합니다, 전체 테이블 스캔을 피하려고한다.
2. 필드는 where 절에서 결정되는 null 값을 피해야한다, 엔진과 같은 인덱스와 전체 테이블 스캔, 사용을 포기하게됩니다 : NUM 0 납입의 기본 값에 제공 될 수있다 null의 t에서 선택 ID를 보장하기 위해 NUM 테이블 열 값이 널이 다음 쿼리 아니다 : t에서 선택 ID = 0 여기서 NUM
3 그렇지 않으면 엔진이 인덱스와 전체 테이블 스캔을 사용하여 줄 것이다, 절! = 또는 <> 연산자를 피해야한다.
4 연결하거나 조건이 엔진은 같은 인덱스와 전체 테이블 스캔, 사용을 포기하게됩니다 where 절에서 피해야한다 : t에서 선택 ID를 어디서 NUM = 10 = 20이 쿼리를 수행 할 수 NUM : 선택 ID와 t 곳 t에서 NUM = 10 노동 조합의 모든 ID를 선택 어디에 NUM = 20
사용할 수 사이의 연속 값 t에서 선택 자료 NUM (1,2,3)에서 : 선택 5.in ID와 같은, 그렇지 않으면 전체 테이블 스캔으로 이어질뿐만에주의 사용되어야 t의 위치를 NUM (1)과 (3) 사이
6. 다음 쿼리는 전체 테이블 스캔으로 이어질 것입니다 : 이름이 '% 리'개선하기 위해 효율성과 같은 전체 텍스트 검색 간주 될 수 t에서 ID를 선택합니다.
7. WHERE 절에있는 매개 변수는 전체 테이블 스캔으로 이어질 것입니다 경우. 런타임시 SQL은 로컬 변수를 해결할 수 있지만, 최적화가 실행 액세스 플랜의 선택을 연기 할 수 없기 때문에, 그것은 컴파일시에 선택해야합니다. 그러나, 컴파일시에 액세스 계획을 수립하는 경우, 변수의 값은 알 수없는, 따라서 선택된 인덱스 항목으로 사용할 수 없습니다. NUM = @ 납입 인덱스를 사용하여 쿼리를 강제로 변경 될 수 있습니다 t에서 선택 ID : 다음 문은 전체 테이블 스캔 수행으로 (지수 (인덱스 이름))와 t에서 선택 ID를 어디서 NUM = @ NUM
8. 필드는 엔진이 인덱스와 전체 테이블 스캔을 사용하여 포기하게됩니다 WHERE 절 표현식에서 작동하도록 피해야한다. 이와 같이하여 num / 2 = 100로 변경한다 t에서 선택 자료 : t에서 선택 자료 여기서 NUM = 100 * 2
9. 필드는 엔진이 인덱스와 전체 테이블 스캔을 사용하여 포기하게됩니다 WHERE 절에서 함수 작업을 피해야한다. 예컨대 : t에서 선택 번호 문자열 (이름, 1,3) = 'ABC'이름의 ID ABC로 시작하는 곳
읽어야 할 사람 :
여기서 이름과 같은 'ABC %'t에서 ID를 선택
10. WHERE 절에 기능, 산술 연산, 또는 기타 표현을 수행하지 마십시오 "="왼쪽 또는 시스템이 제대로 색인이 작동하지 않을 수 있습니다.
인덱스가 지수 인 경우에는 시스템을 위해 첫 번째 필드에 인덱스를 사용하며, 상기 인덱스 필드를 사용하는 조건으로 11. 조건 달리 인덱스가 사용되지 않는 인덱스를 사용하고해야 해당 필드의 순서가 순서 인덱스와 일치하므로 가능한 한 많이.
12. 이러한 빈 테이블 구조를 만들 필요로 이해가되지 않는 쿼리를 작성하지 마십시오 COL1을 선택, COL2를 #T로 t 어디에서 1 = 0
이 코드는 어떤 결과 집합을 반환하지만, 시스템 리소스를 소비하며이 교체해야하지 않습니다
(...) 테이블 #T를 만들
13.很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15. 索引并不是越多越好，索引固然可 以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。
16. 应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27. 与临时表一样，游标并不是不可使 用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。