SQL Server索引管理之六大铁律
通过索引,可以加快数据的查询速度和减少系统的响应时间;可以使表和表之间的连接速度加快。但是,不是在任何时候使用索引都能够达到这种效果。若在不恰当的场合下,使用索引反而会事与愿违。 索引是以表列为基础的数据库对象。索引中保存着表中排序的索引列
通过索引,可以加快数据的查询速度和减少系统的响应时间;可以使表和表之间的连接速度加快。但是,不是在任何时候使用索引都能够达到这种效果。若在不恰当的场合下,使用索引反而会事与愿违。
索引是以表列为基础的数据库对象。索引中保存着表中排序的索引列,并且纪录了索引列在数据库表中的物理存储位置,实现了表中数据的逻辑排序。通过索引,可以加快数据的查询速度和减少系统的响应时间;可以使表和表之间的连接速度加快。
但是,不是在任何时候使用索引都能够达到这种效果。若在不恰当的场合下,使用索引反而会事与愿违。所以,在SQL Server数据库中使用索引的话,还是需要遵守一定的规则。
铁律一:天下没有免费的午餐,使用索引是需要付出代价的
索引的优点有目共睹,但是,却很少有人关心过采用索引所需要付出的成本。若数据库管理员能够对索引所需要付出的代价有一个充分的认识,也就不会那么随意到处建立索引了。
仔细数数,其实建立索引的代价还是蛮大的。如创建索引和维护索引都需要花费时间与精力。特别是在数据库设计的时候,数据库管理员为表中的哪些字段需要建立索引,要调研、要协调。如当建有索引的表中的纪录又增加、删除、修改操作时,数据库要对索引进行重新调整。虽然这个工作数据库自动会完成,但是,需要消耗服务器的资源。当表中的数据越多,这个消耗的资源也就越多。如索引是数据库中实际存在的对象,所以,每个索引都会占用一定的物理空间。若索引多了,不但会占用大量的物理空间,而且,也会影响到整个数据库的运行性能。
可见,数据库管理员若要采用索引来提高系统的性能,自身仍然需要付出不少的代价。数据库管理员现在要考虑的就是如何在这两个之间取得一个均衡。或者说,找到一个回报与投入的临界点。
铁律二:对于查询中很少涉及的列或者重复值比较多的列,不要建立索引
在查询的时候,如果我们不按某个字段去查询,则在这个字段上建立索引也是浪费。如现在有一张员工信息表,我们可能按员工编号、员工姓名、或者出身地去查询员工信息。但是,我们往往不会按照身份证号码去查询。虽然这个身份证号码是唯一的。此时,即使在这个字段上建立索引
相关文档:
1不用在sql语句使用系统默认的保留关键字
2尽量用exists 和 not exists 代替 in 和 not in
这条在sql2005之后,在索引一样,统计信息一样的情况下,exists ,in效果是一样的。
以AdventureWorks数据库为例,查询在H ......
应用示例:
-- 创建2个测试表
CREATE TABLE [dbo].[Table_2019]([Data] [nchar](2019) NOT NULL)
CREATE TABLE [dbo].[Table_2020]([Data] [nchar](2020) NOT NULL)
go
-- 填充数据
declare @i int
set @i = 0
while(@i < 20)
begin
insert Table_2019(Data) values('')
  ......
折腾了我半天终于搞定了
参考了这个文章:http://doc.javanb.com/hibernate-reference-3-2-0-zh/ch16.html
final static String querySql = "select {enterprise.*}, {dict.*} ,{balancd.*}, {weightinfo.*} "
+ "from weight_info weightinfo left outer join t_dict dict on {weightinf ......