sqlserver性能优化建议

1、索引

1.1、索引的数量不是越多越好，因为索引多了会影响数据增删改的速度，从而引起死锁，所以索引应该建立在查询频率很高的字段上。

1.2、索引列的选择。索引列应该建立在列值重复率低的列上。因为当列值重复率高的时候，索引的查询效率比较低。

1.3、对于有聚集索引的表，表数据的存储顺序是按照聚集索引的第一个列升序排列的。这里顺便提一下，当我们不使用order by来查询一个表的数据时，数据是按照ID自增主键升序显示的，这足以证明刚才的论点。

1.4、主键和聚集索引的关系。主键不允许有重复值，但聚集索引允许有重复值；主键即可以创建在聚集索引上，也可以创建在非聚集索引上，如果没有指定nonclustered或者clustered，则默认是聚集索引；

1.5、复合索引(也就是由多个字段组成的索引)。当我们使用where查询时，复合索引的第一个列必须包含在查询列中，不然不会走索引查找，但是这个查询列不是必须在where查询列的第一个列中，可以在任意位置。

1.6、当使用where查询时，如果你想走索引查找，必须保证查询列的数据类型和查询值的数据类型一致，不然会导致隐式转换，sqlserver就不会走索引查找了，而是全表扫描。还有不要对查询列用函数做一些转换，不然也会导致索引失效，比如cast、convert等函数。

1.7、覆盖索引，只能用于非聚集索引。当我们使用select where查询时，where查询走的是索引查找，但是select查询的字段中有不存在于索引中的字段，此时可以使用include覆盖索引。如果这种情况下不使用覆盖索引，那就会走书签查找(keylookup)，这种查询也是比较耗时的。当然凡事都有一个度，覆盖索引也不能包含太多的列，否则会加大索引的体积，导致索引的查找速度变慢。

2、建议

2.1、尽量少用order by、group by，因为排序对性能损耗很大。上面说过，如果表有聚集索引，那么表数据的存储顺序是根据聚集索引的第一个列升序存储的，所以如果可以，可以考虑利用这个排序。group by是要先排序的

2.2、尽量少用select *，因为这个会导致书签查找或者全表扫描，增加查询时间，我们只取需要的字段即可

2.3、我们在写程序时，经常需要在一个循环中写查询，循环有多少次就要执行多少次查询。当循环次数少时，问题不是很大。但是次数多时(大于100)，程序就会出现卡顿。因为程序要和数据库不断建立连接、执行查询、断开链接，这是很耗时的。所以出现这种情况时，必须想办法把这些查询合并成一个或多个查询，减少建立连接和查询的次数。常见的方法使用in关键字，或者优化程序的逻辑。

2.4、尽量少用存储过程来执行程序的功能逻辑查询。存储过程主要用来执行一些数据库维护相关的代码，比如和维护计划搭配使用实现自动表分区。也就是说存储过程主要用来执行与数据库本身相关的任务，不应该涉及程序逻辑。

2.5、尽量少使用触发器。触发器是隐式执行的，当我们排查问题的时候，很容易忽略触发器的影响。

2.6、当我们的应用程序上线以后，可以使用sql trace来收集查询时间大于1秒(这个时间根据程序允许的延时时间来定)的查询。我们获取到查询耗时长的查询语句后，使用执行计划来分析这个查询，根据分析的结果，选择合适的优化方案(建索引或者优化查询语句)。

2.7、尽量少使用join来连接大表查询。

2.8、当我们不确定一个查询是否会用到索引查询时，可以使用执行计划分析这个查询。我们要先清空缓存，然后再分析。但是不要在生产环境执行这个。

3、表分区

我们都知道，当一个表数据量很大的时候，比如1天10万条数据及以上，这时候就需要建立表分区。那么应该怎样建立合适的表分区呢？

3.1、一般情况下，我们会选择使用日期列作为分区列，把一个时间段的数据存储在一个文件中。当然根据业务逻辑的需要，也可以使用其他列作为分区列，比如项目id。

3.2、当第一次建立分区后，后面随着时间的推移，需要不断增加新的分区，那增加新分区该怎么实现呢？首先手动添加分区是不现实的，因为人的精力和记忆力是有限的，很可能会忘记定时添加新的分区。那么只能通过自动化来实现。具体实现方法：写一个自动添加新分区的存储过程，然后在维护计划中定期调用这个存储过程。

3.3、对于分区的时间间隔也是要根据数据量的确定的。有的表一天有10万行数据，有的表一天有100万行数据，有的甚至一天有1000万行数据，那么分区的时间间隔也要根据数据量的增加而减少。