SQLServer索引调优实践
索引的重要性
数据库性能优化中索引绝对是一个重量级的因素,可以说,索引使用不当,其它优化措施将毫无意义。
聚簇索引(Clustered Index)和非聚簇索引 (Non- Clustered Index)
最通俗的解释是:聚簇索引的顺序就是数据的物理存储顺序,而对非聚簇索引的索引顺序与数据物理排列顺序无关。举例来说,你翻到新华字典的汉字“爬”那一页就是P开头的部分,这就是物理存储顺序(聚簇索引);而不用你到目录,找到汉字“爬”所在的页码,然后根据页码找到这个字(非聚簇索引)。
下表给出了何时使用聚簇索引与非聚簇索引:
动作
使用聚簇索引
使用非聚簇索引
列经常被分组排序
应
应
返回某范围内的数据
应
不应
一个或极少不同值
不应
不应
小数目的不同值
应
不应
大数目的不同值
不应
应
频繁更新的列
不应
应
外键列
应
应
主键列
应
应
频繁修改索引列
不应
应
聚簇索引的唯一性
正式聚簇索引的顺序就是数据的物理存储顺序,所以一个表最多只能有一个聚簇索引,因为物理存储只能有一个顺序。正因为一个表最多只能有一个聚簇索引,所以它显得更为珍贵,一个表设置什么为聚簇索引对性能很关键。
初学者最大的误区:把主键自动设为聚簇索引
因为这是SQLServer的默认主键行为,你设置了主键,它就把主键设为聚簇索引,而一个表最多只能有一个聚簇索引,所以很多人就把其他索引设置为非聚簇索引。这个是最大的误区。甚至有的主键又是无意义的自动增量字段,那样的话Clustered index对效率的帮助,完全被浪费了。
刚才说到了,聚簇索引性能最好而且具有唯一性,所以非常珍贵,必须慎重设置。一般要根据这个表最常用的SQL查询方式来进行选择,某个字段作为聚簇索引,或组合聚簇索引,这个要看实际情况。
事实上,建表的时候,先需要设置主键,然后添加我们想要的聚簇索引,最后设置主键,SQLServer就会自动把主键设置为非聚簇索引(会自动根据情况选择)。如果你已经设置了主键为聚簇索引,必须先删除主键,然后添加我们想要的聚簇索引,最后恢复设置主键即可。
记住我们的最终目的就是在相同结果集情况下,尽可能减少逻辑IO。
我们先从一个实际使用的简单例子开始。
一个简单的表:
CREATE TABLE [dbo]
相关文档:
DATEDIFF(datepart, startdate, enddate)
Datepart Abbreviations
year yy, yyyy
quarter qq, q
month mm, m
......
/******************************
系统函数
******************************/
--convert 用来转变数据类型
--convert (data_type[(length)], expression [, style])
select convert(int,convert(varchar(5),12345)+'678')+1 --返回12345679
--cast 也是用来转换数据类型
--cast(expression as data_type[(l ......
//总记录数
function sumRecord()
{
var conn= Server.CreateObject("ADODB.connection");
var rs= Server.CreateObject("adodb.recordset");
conn.open("PROVIDER=SQLOLEDB;DATA SOURCE=127.0.0.1;UID=sa;PWD=123456;DATABASE=test");
var sql = "select count(*) as RecordCount from baoming";
rs.open(sql, ......
在主数据库文件进行大量的删除(新增,修改都会有日志),日志文件有1.5G。昨天还原数据库时初始值也才1MB。必须清除掉,不然太占空间了。上网找了个清除日志的方法。顺利将日志文件log.ldf从1.5G变为了1M。 我执行如下:
1.清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
2.截断事务日志:
BACKUP LOG ......
在临时表
create table #T (…)
和表变量
declare @T table (…)
之间主要有3个理论上的不同。
第一个不同使事务日志不会记录表变量。因此,它们脱离了事务机制的范围,从下面的例子可显而易见:
create table #T (s varchar(128))
declare @T table (s varchar(128))
insert into #T select 'old va ......