大数据高并发数据优化方法

一.适当增加冗余表（不要用自增属性字段作为主键与子表关联，不便于系统的迁移和数据恢复）

二.表的设计具体注意的问题：

    1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
    2、能够用数字类型的字段尽量选择数字类型，能提升查询连接性能，减少存储开销。

    3、不可变char型和可变varchar型都是8000字节,char查询快，但耗存储空间；varchar查询相对慢一些但节省存储空间。对于长度变化不大字段可选择CHAR，对于长度变化大的字段可以选择VARCHAR。

    4、字段的长度应该尽可能的设得短一些，可提高查询效率，且在建立索引的时候也可以减少资源的消耗。

三.SQL编写时需注意的点：

1.在where 中字段判断null 值时(需要进行全表扫描)，可将num设置默认值0，通过num=0查找

2.不在 where 中使用!=或<>操作符。

3.不在 where 中使用 or 连接条件(进行全表扫描)，可用union

4.慎用in 和 not in，因为IN只能直接搜索表中的数据。对于连续的数值，用 between 。

5.在索引过的字符数据中，不使用非打头字母搜索。这也使得引擎无法利用索引。 

6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

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

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

11.很多时候用 exists代替IN是一个好的选择.如果你想校验表里是否存在某条纪录，不要用count(*)，]可以用EXISTS代替。 
经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如： 
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替 
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key) 
SELECT a.hdr_key FROM hdr_tbl a 
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL 
SELECT hdr_key FROM hdr_tbl 
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl) 
三种写法都可以得到同样正确的结果，但是效率依次降低。

12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

13.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

14.如果使用了临时表，在存储过程最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table .
15.在所有存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

16.尽量避免大事务操作，提高系统并发能力。
17.避免使用不兼容的数据类型。如float和int、char和varchar、binary和varbinary是不兼容

18.能用DISTINCT的就不用GROUP BY 
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID  可改为： SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10

19.能用UNION ALL就不要用UNION 
20.尽量不要用SELECT INTO语句。 SELECT INOT 语句会导致表锁定，阻止其他用户访问该表。

通过查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。 

四、建立高效的索引

　 创建索引一般有以下两个目的：

    1. 维护被索引列的唯一性和提供快速访问表中数据的策略。大型数据库有两种索引即簇索引和非簇索引。无簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部。而有簇索引的表，数据在物理上会按照簇索引键的顺序存储，且一个表只允许有一个簇索引。因此，添加索引均能提高按索引列find速度，但会降低Insert、Update、Delete操作性能。作为一条规则，通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列[字段]采用非成组索引。 
实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引和非聚集索引。下面，我们举例来说明一下聚集索引和非聚集索引的区别： 
其实，通过汉语字典的拼音目录就是一个聚集索引。某个字的正文先后位置顺序与目录先后位置顺序一致称为“聚集索引”。 
但结合“部首目录”和“检字表”而查到的字的排序，我们通过先找到目录中的结果，然后再翻到您所需要的页码。某个字的正文先后位置顺序与目录先后位置顺序不一致。，目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 
所以每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

（一）何时使用聚集索引或非聚集索引 
下面的表总结了何时使用聚集索引或非聚集索引（很重要）。 
动作描述                       使用聚集索引                     使用非聚集索引 
返回某范围内的数据               应                                   不应 
一个或极少不同值               不应                                   不应 
小数目的不同值                      应                                   不应 
大数目的不同值                   不应                                      应 
频繁更新的列                      不应                                      应 
外键列                                    应                                      应 
主键列                                    应                                      应 
频繁修改索引列                  不应                                      应

（二）索引使用的误区
1、主键不一定就是聚集索引 
显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。

2、吧所有需要提高查询速度的字段都加进聚集索引不一定能提高查询速度 。聚合索引的前导列一定要是使用最频繁的列。

（三）其他注意事项 
“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。 
所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥