MySQL 的索引优化

索引类似大学图书馆建书目索引，可以提高数据检索的效率，降低数据库的IO成本。MySQL在300万条记录左右性能开始逐渐下降，虽然官方文档说500~800w记录，所以大数据量建立索引是非常有必要的。MySQL提供了Explain，用于显示SQL执行的详细信息，可以进行索引的优化。

一、导致SQL执行慢的原因

1.硬件问题。如网络速度慢，内存不足，I/O吞吐量小，磁盘空间满了等。

2.没有索引或者索引失效。（一般在互联网公司，DBA会在半夜把表锁了，重新建立一遍索引，因为当你删除某个数据的时候，索引的树结构就不完整了。所以互联网公司的数据做的是假删除.一是为了做数据分析,二是为了不破坏索引）

3.数据过多（分库分表）

4.服务器调优及各个参数设置（调整my.cnf）

二、分析原因时，一定要找切入点

1.先观察，开启慢查询日志，设置相应的阈值（比如超过3秒就是慢SQL），在生产环境跑上个一天过后，看看哪些SQL比较慢。

2.Explain和慢SQL分析。比如SQL语句写的烂，索引没有或失效，关联查询太多（有时候是设计缺陷或者不得以的需求）等等。

3.Show Profile是比Explain更近一步的执行细节，可以查询到执行每一个SQL都干了什么事，这些事分别花了多少秒。

4.找DBA或者运维对MySQL进行服务器的参数调优。

三、什么是索引？

MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。我们可以简单理解为：快速查找排好序的一种数据结构。Mysql索引主要有两种结构：B+Tree索引和Hash索引。我们平常所说的索引，如果没有特别指明，一般都是指B树结构组织的索引(B+Tree索引)。索引如图所示：

最外层浅蓝色磁盘块1里有数据17、35（深蓝色）和指针P1、P2、P3（黄色）。P1指针表示小于17的磁盘块，P2是在17-35之间，P3指向大于35的磁盘块。真实数据存在于子叶节点也就是最底下的一层3、5、9、10、13……非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35。

查找过程：例如搜索28数据项，首先加载磁盘块1到内存中，发生一次I/O，用二分查找确定在P2指针。接着发现28在26和30之间，通过P2指针的地址加载磁盘块3到内存，发生第二次I/O。用同样的方式找到磁盘块8，发生第三次I/O。

真实的情况是，上面3层的B+Tree可以表示上百万的数据，上百万的数据只发生了三次I/O而不是上百万次I/O，时间提升是巨大的。

四、Explain 分析

前文铺垫完成，进入实操部分，先来插入测试需要的数据：

CREATE TABLE `user_info` (

  `id`   BIGINT(20)  NOT NULL AUTO_INCREMENT,

  `name` VARCHAR(50) NOT NULL DEFAULT '',

  `age`  INT(11)              DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `name_index` (`name`)

)ENGINE = InnoDB DEFAULT CHARSET = utf8;

INSERT INTO user_info (name, age) VALUES ('xys', 20);

INSERT INTO user_info (name, age) VALUES ('a', 21);

INSERT INTO user_info (name, age) VALUES ('b', 23);

INSERT INTO user_info (name, age) VALUES ('c', 50);

INSERT INTO user_info (name, age) VALUES ('d', 15);

INSERT INTO user_info (name, age) VALUES ('e', 20);

INSERT INTO user_info (name, age) VALUES ('f', 21);

INSERT INTO user_info (name, age) VALUES ('g', 23);

INSERT INTO user_info (name, age) VALUES ('h', 50);

INSERT INTO user_info (name, age) VALUES ('i', 15);

CREATE TABLE `order_info` (

  `id`           BIGINT(20)  NOT NULL AUTO_INCREMENT,

  `user_id`      BIGINT(20)           DEFAULT NULL,

  `product_name` VARCHAR(50) NOT NULL DEFAULT '',

  `productor`    VARCHAR(30)          DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`)

)ENGINE = InnoDB DEFAULT CHARSET = utf8;

INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'WHH');

INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p2', 'WL');

INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'DX');

INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p1', 'WHH');

INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p5', 'WL');

INSERT INTO order_info (user_id, product_name, productor) VALUES (3, 'p3', 'MA');

INSERT INTO order_info (user_id, product_name, productor) VALUES (4, 'p1', 'WHH');

INSERT INTO order_info (user_id, product_name, productor) VALUES (6, 'p1', 'WHH');

INSERT INTO order_info (user_id, product_name, productor) VALUES (9, 'p8', 'TE');

初体验，执行Explain的效果：

索引使用情况在possible_keys、key和key_len三列，接下来我们先从左到右依次讲解。

1.id

--id相同,执行顺序由上而下

explain select u.*,o.* from user_info u,order_info o where u.id=o.user_id;

--id不同,值越大越先被执行

explain select * from user_info where id=(select user_id from order_info where product_name ='p8');

2.select_type

可以看id的执行实例，总共有以下几种类型：

SIMPLE：表示此查询不包含 UNION 查询或子查询
PRIMARY：表示此查询是最外层的查询
SUBQUERY：子查询中的第一个 SELECT
UNION：表示此查询是 UNION 的第二或随后的查询
DEPENDENT UNION： UNION 中的第二个或后面的查询语句, 取决于外面的查询
UNION RESULT, UNION 的结果
DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.
DERIVED：衍生，表示导出表的SELECT（FROM子句的子查询）

3.table

table表示查询涉及的表或衍生的表：

explain select tt.* from (select u.* from user_info u,order_info o where u.id=o.user_id and u.id=1) tt

id为1的<derived2>的表示id为2的u和o表衍生出来的。

4.type

type 字段比较重要，它提供了判断查询是否高效的重要依据依据。通过 type 字段，我们判断此次查询是全表扫描还是索引扫描等。

type 常用的取值有:

system: 表中只有一条数据，这个类型是特殊的 const 类型。
const: 针对主键或唯一索引的等值查询扫描，最多只返回一行数据。 const 查询速度非常快，因为它仅仅读取一次即可。例如下面的这个查询，它使用了主键索引，因此 type 就是 const 类型的：explain select * from user_info where id = 2；
eq_ref: 此类型通常出现在多表的 join 查询，表示对于前表的每一个结果，都只能匹配到后表的一行结果。并且查询的比较操作通常是 =，查询效率较高。例如：explain select * from user_info, order_info where user_info.id = order_info.user_id;
ref: 此类型通常出现在多表的 join 查询，针对于非唯一或非主键索引，或者是使用了最左前缀规则索引的查询。例如下面这个例子中，就使用到了 ref 类型的查询：explain select * from user_info, order_info where user_info.id = order_info.user_id AND order_info.user_id = 5
range: 表示使用索引范围查询，通过索引字段范围获取表中部分数据记录。这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中。例如下面的例子就是一个范围查询：explain select * from user_info where id between 2 and 8；
index: 表示全索引扫描(full index scan)，和 ALL 类型类似，只不过 ALL 类型是全表扫描，而 index 类型则仅仅扫描所有的索引，而不扫描数据。index 类型通常出现在：所要查询的数据直接在索引树中就可以获取到, 而不需要扫描数据。当是这种情况时，Extra 字段会显示 Using index。
ALL: 表示全表扫描，这个类型的查询是性能最差的查询之一。通常来说，我们的查询不应该出现 ALL 类型的查询，因为这样的查询在数据量大的情况下，对数据库的性能是巨大的灾难。如一个查询是 ALL 类型查询，那么一般来说可以对相应的字段添加索引来避免。

通常来说, 不同的 type 类型的性能关系如下:

ALL < index < range ~ index_merge < ref < eq_ref < const < system

ALL 类型因为是全表扫描，因此在相同的查询条件下，它是速度最慢的。而 index 类型的查询虽然不是全表扫描，但是它扫描了所有的索引，因此比 ALL 类型的稍快.后面的几种类型都是利用了索引来查询数据，因此可以过滤部分或大部分数据，因此查询效率就比较高了。

5.possible_keys

它表示 mysql 在查询时，可能使用到的索引。注意，即使有些索引在 possible_keys 中出现，但是并不表示此索引会真正地被 mysql 使用到。 mysql 在查询时具体使用了哪些索引，由 key 字段决定。

6.key

此字段是 mysql 在当前查询时所真正使用到的索引。比如请客吃饭,possible_keys是应到多少人，key是实到多少人。当我们没有建立索引时：

explain select o.* from order_info o where o.product_name= 'p1' and o.productor='whh';

create index idx_name_productor on order_info(productor);

drop index idx_name_productor on order_info;

建立复合索引后再查询：

7.key_len

表示查询优化器使用了索引的字节数，这个字段可以评估组合索引是否完全被使用。

8.ref

这个表示显示索引的哪一列被使用了，如果可能的话,是一个常量。前文的type属性里也有ref，注意区别。

9.rows

rows 也是一个重要的字段，mysql 查询优化器根据统计信息，估算 sql 要查找到结果集需要扫描读取的数据行数，这个值非常直观的显示 sql 效率好坏，原则上 rows 越少越好。可以对比key中的例子，一个没建立索引钱，rows是9，建立索引后，rows是4。

10.extra

explain 中的很多额外的信息会在 extra 字段显示, 常见的有以下几种内容:

using filesort ：表示 mysql 需额外的排序操作，不能通过索引顺序达到排序效果。一般有 using filesort都建议优化去掉，因为这样的查询 cpu 资源消耗大。
using index：覆盖索引扫描，表示查询在索引树中就可查找所需数据，不用扫描表数据文件，往往说明性能不错。
using temporary：查询有使用临时表, 一般出现于排序，分组和多表 join 的情况，查询效率不高，建议优化。
using where ：表名使用了where过滤。

五、优化案例

explain select u.*,o.* from user_info u LEFT JOIN order_info o on u.id=o.user_id;

执行结果，type有ALL，并且没有索引：

开始优化，在关联列上创建索引，明显看到type列的ALL变成ref，并且用到了索引，rows也从扫描9行变成了1行：

这里面一般有个规律是：左链接索引加在右表上面，右链接索引加在左表上面。

六、是否需要创建索引？

索引虽然能非常高效的提高查询速度，同时却会降低更新表的速度。实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的。

七索引和查询优化

1. 不使用顺序查找，因为顺序查找比较慢，通过特定数据结构的特点来提升查询速度，这种数据结构就是可以理解成索引。

2. 索引一般以文件形式存储在磁盘上，索引检索需要磁盘I/O操作，为了尽量减少磁盘I/O。磁盘往往不是严格按需读取，而是每次都会预读，而且主存和磁盘以页为单位交换数据，所以在读取的数据不在主存中时，会从磁盘中读取一批数据（页）到主存中。

3. 不管在哪种程序优化上，要想快速挺高性能，直接将常用的、少变更的数据直接读取到内存中，使用的时候就直接在内存上读取，而不去磁盘上读取，减少I/O操作，这样就能使程序快上10倍以上。但由于内存容量的限制，也不可能将所有的数据都放内存中。

MySQL索引分类

普通索引：最基本的索引，没有任何限制。

唯一索引：与”普通索引”类似，不同的就是：索引列的值必须唯一，但允许有空值。

主键索引：它是一种特殊的唯一索引，不允许有空值。

全文索引：仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间。

组合索引：为了更多的提高mysql效率可建立组合索引，遵循”最左前缀“原则。

覆盖索引(Covering Indexes)就是直接走的索引，直接在内存中就拿到值，不需要查询数据库。如分页就要走覆盖索引，因为性能比较高。

聚簇索引(Clustered Indexes)，主键就是聚集索引。聚簇索引保证关键字的值相近的元组存储的物理位置也相同（所以字符串类型不宜建立聚簇索引，特别是随机字符串，会使得系统进行大量的移动操作），且一个表只能有一个聚簇索引。因为由存储引擎实现索引，所以，并不是所有的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。

非聚簇索引：二级索引叶子节点保存的不是指行的物理位置的指针，而是行的主键值。这意味着通过二级索引查找行。InnoDB对主键建立聚簇索引。如果你不指定主键，InnoDB会用一个具有唯一且非空值的索引来代替。如果不存在这样的索引，InnoDB会定义一个隐藏的主键，然后对其建立聚簇索引。一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二级索引的基础。

优化要注意的一些事（重点）

1. 索引其实就是一种归类方式，当某一个字段属性都不能归类，建立索引后是没什么效果的，或归类就二种（0和1），且各自都数据对半分，建立索引后的效果也不怎么强。

2. 主键的索引是不一样的，要区别理解。

3. 当时间存储为时间戳保存的可以建立前缀索引。

4. 在什么是字段上建立索引，需要根据查询条件而定，不要一上来就建立索引，浪费内存还有可能用不到。

5. 大字段（blob）不要建立索引，查询也不会走索引。

6. 常用建立索引的地方：

主键的聚集索引
外键索引
类别只有0和1就不要建索引了，没有意义，对性能没有提升，还影响写入性能
用模糊其实是可以走前缀索引

7. 唯一索引一定要小心使用，它带有唯一约束，由于前期需求不明等情况下，可能造成我们对于唯一列的误判。

8. 由于我们建立索引并想让索引能达到最高性能，这个时候我们应当充分考虑该列是否适合建立索引，可以根据列的区分度来判断，区分度太低的情况下可以不考虑建立索引，区分度越高效率越高。

SELECT COUNT(DISTINCT 列_xx)/COUNT(*) FROM 表

9. 写入比较频繁的时候，不能开启MySQL的查询缓存，因为在每一次写入的时候不光要写入磁盘还的更新缓存中的数据。

10. 建索引的目的：

1）加快查询速度，使用索引后查询有迹可循。

2）减少I/O操作，通过索引的路径来检索数据，不是在磁盘中随机检索。

3）消除磁盘排序，索引是排序的，走完索引就排序完成。

11. 其实建索引的原理就是将磁盘I/O操作的最小化，不在磁盘中排序，而是在内存中排好序，通过排序的规则去指定磁盘读取就行，也不需要在磁盘上随机读取。

12. 由于磁盘整理磁盘碎片，所有有的时候我们也可以通过建立聚集索引来减少这一类的问题。

13. 当一个表中有100万数据，而经常用到的数据只有40万或40万以下，是不用考虑建立索引的，没什么性能提升。

14. 什么时候不适合建立索引：

1）频繁更新的字段不适合建立索引

2）where条件中用不到的字段不适合建立索引，都用不到建立索引没有意义还浪费空间

3）表数据可以确定比较少的不需要建索引

4）数据重复且发布比较均匀的的字段不适合建索引（唯一性太差的字段不适合建立索引），例如性别，真假值

5）参与列计算的列不适合建索引，如：

select * from table where amount+100>1000，-- 这样是不走索引的，可以改造为：select * from table where amount>1000-100。

15. 使用count统计数据量的时候建议使用count(*)而不是count(列)，因为count(*)MySQL是做了优化的。

16. 二次SQL查询区别不大的时候，不能按照二次执行的时间来判断优化结果，没准第一次查询后又保存缓存数据，导致第二次查询速度比第二次快，很多时候我们看到的都是假象。

17. 什么时候开MySQL的查询缓存，交易系统（写多、读少）、SQL优化测试，建议关闭查询缓存，论坛文章类系统（写少、读多），建议开启查询缓存。

18. Explain 执行计划只能解释SELECT操作。

19. 查询优化可以考虑让查询走索引，走索引能提升查询速度，索引覆盖是最快的，如下就是让分页走覆盖索引提高查询速度。

Select * from fentrust e

Inner join (select fid from fentrust limit 4100000, 10) a on a.fid = e.fid

20. 子查询比join快，虽然规律不绝对，但对大表多数有效

21. 复杂SQL语句优化的思路：

1）首先考虑在一个表中能不能取到有关的信息，尽量少关联表

2）关联条件争取都走主键或外键查询条件，能走到对应的索引

3）争取在满足业务上走小集合数据查找

4）INNER JOIN 和子查询哪个更快，场景不一致速度也不同

22. where条件多条件一定要按照小结果集排大结果集前面

23. 尽量避免大事务操作，提高系统并发能力，有时无法避免，改用定时器延迟处理。

24. 什么情况不走索引：

SELECT ` famount ` FROM ` fentrust ` WHERE ` famount `+10=30;-- 不会使用索引,因为所有索引列参与了计算

SELECT `famount` FROM `fentrust` WHERE LEFT(`fcreateTime`,4) <1990; -- 不会使用索引,因为使用了函数运算,原理与上面相同

SELECT * FROM ` fuser` WHERE `floginname` LIKE‘138%' -- 走索引

SELECT * FROM ` fuser ` WHERE ` floginname ` LIKE "%7488%" -- 不走索引 -- 正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因 -- 字符串与数字比较不使用索引;

EXPLAIN SELECT * FROM `a` WHERE `a`=1 -- 不走索引

select * from fuser where floginname='xxx' or femail='xx' or fstatus=1 --如果条件中有or,即使其中有条件带索引也不会使用。换言之,就是要求使用的所有字段,都必须建立索引, 我们建议大家尽量避免使用or 关键字

25. 如果MySQL估计使用全表扫描要比使用索引快，则不使用索引。

26. 使用UNION ALL 替换OR多条件查询并集。

27. 在大数据表删除也是一个问题，避免删除过程数据库奔溃，可以考虑分配删除，一次删1000条，删完后等一会继续删除

delete from logs where log_date <= ’2012-11-01’ limit 1000

28. 大数据表优化：

1）建立汇总表

2）建立流水表

3）分库分表

29. 建立汇总表，首先不用考虑分库分表，使用定时器定时去汇总。

30. 分表，可以按水平或垂直切分。垂直分表其实就是将经常使用的数据和很少使用的数据进行垂直的切分，切分到不同的库，提高单库的数据容量，如：前3个月之前的交易记录就可以放另一个库中。

31. 建立流水表，数据冗余，有这个表记录流水变更就不用去写复杂SQL计算流水。

32. 分库，多数据库相同库结构，分发处理并发能力，但同时带来了数据同步问题，也可以使用分库做主备分离

32. SQL优化顺序：

1）尽量少作计算。

2）尽量少 join。

3）尽量少排序。

4）尽量避免 select *。

5）尽量用 join 代替子查询。

6）尽量少 or。

7）尽量用 union all 代替 union。

8）尽量早过滤。

9）避免类型转换。

10）优先优化高并发的 SQL，而不是执行频率低某些“大”SQL。

11）从全局出发优化，而不是片面调整。

12）尽可能对每一条运行在数据库中的SQL进行 Explain。

33. 如下是30条大数据表优化要点：

1）对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0

3）应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。

4）应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10 union all select id from t where num=20

5）in 和 not in 也要慎用，否则会导致全表扫描，如：select id from t where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了：select id from t where num between 1 and 3

6）下面的查询也将导致全表扫描：select id from t where name like '李%'若要提高效率，可以考虑全文检索。

7）如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num

8）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where num/2=100应改为:select id from t where num=100*2

9）应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where substring(name,1,3)='abc' ，name以abc开头的id 应改为: select id from t where name like 'abc%'

10）不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11）在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

12）不要写一些没有意义的查询，如需要生成一个空表结构：select col1,col2 into #t from t where 1=0 这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样： create table #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）尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

posted @ 2018-05-19 13:20 Frankdeng 阅读(1515) 评论(0) 编辑收藏举报

刷新页面返回顶部

Frankdeng