`
hz_chenwenbiao
  • 浏览: 1008052 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论
文章列表
  使用hibernate search后,就会在加载hibernate配置文件时,自动在本地磁盘里建立索引文件,这个只是一个没有将数据库的记录加入到索引文件里去的,而只有一些必要信息的索引文件,因此,当我们将一个原来存在的索引文件删除后,想将它重建起来,那可以使用如下的方式来重建:   1 在重建的过程中,首先我遇到的问题是如何在使用注解的工程里面获取sessionFactory,这个使用另外加载配置文件的方式再实例化一个spring容器也是可以的,不过,这个spring容器产生的bean实例只是用到sessionFactory,而产生大量的bean实例,这若不用单例模式则很容易出现内在 ...
使用hibernate search来搜索一个加入索引的信息时,可以组合多个搜索条件进行灵活搜索:   方式一: package org.edu.scut.lab24.uam.dao.impl; import java.util.List; import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.queryParser.MultiFieldQueryParser; import org.apache.lucene.queryParser.QueryPa ...
本文将介绍利用SQL建立索引的方法。   假设你想找书中的某一个句子。你可以一页一页地逐页搜索,但这会花很多时间。而通过使用索引,你可以很快地找到你要搜索的主题。   表的索引与附在一本书后面的索引非常相似。它可以极大地提高查询的速度。对一个较大的表来说,通过加索引,一个通常要花费几个小时来完成的查询只要几分钟就可以完成。因此没有理由对需要频繁查询的表增加索引。   注意:   当你的内存容量或硬盘空间不足时,也许你不想给一个表增加索引。对于包含索引的数据库,SQL Sever需要一个可观的额外空间。例如,要建立一个聚簇索引,需要大约1.2倍于数据大小的空间。要看一看一个表的索引在数 ...
                 何时使用聚集索引或非聚集索引 下面的表总结了何时使用聚集索引或非聚集索引(很重要)。 动作描述 使用聚集索引
二、改善SQL语句   很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解。比如:   select * from table1 where name='zhangsan' and tID > 10000   和执行:   select * from table1 where tID > 10000 and name='zhangsan'   一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那么后一句仅仅从表的10000条以后的记录中 ...
4 、日期列不会因为有分秒的输入而减慢查询速度   下面的例子中,共有100万条数据,2004年1月1日以后的数据有50万条,但只有两个不同的日期,日期精确到日;之前有数据50万条,有5000个不同的日期,日期精确到秒。   select gid,fariqi,neibuyonghu,reader,title from Tgongwen   where fariqi>'2004-1-1' order by fariqi   用时:6390毫秒   select gid,fariqi,neibuyonghu,reader,title from Tgongwen   where f ...
(四)其他书上没有的索引使用经验总结   1、用聚合索引比用不是聚合索引的主键速度快   下面是实例语句:(都是提取25万条数据)   select gid,fariqi,neibuyonghu,reader,title from Tgongwen   where fariqi='2004-9-16'   使用时间:3326毫秒   select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000   使用时间:4470毫秒   这里,用聚合索引比用不是聚合索引的主键速度快了近1/4。   ...
2、只要建立索引就能显著提高查询速度   事实上,我们可以发现上面的例子中,第2、3条语句完全相同,且建立索引的字段也相同;不同的仅是前者在fariqi字段上建立的是非聚合索引,后者在此字段上建立的是聚合索引,但查询速度却有着天壤之别。所以,并非是在任何字段上简单地建立索引就能提高查询速度。   从建表的语句中,我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中,我们每天都会发几个文件,这几个文件的发文日期就相同,这完全符合建立聚集索引要求的:“既不能绝大多数都相同,又不能只有极少数相同”的规则。由此看来,我们建立“适 ...
(三)结合实际,谈索引使用的误区   理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引,但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区,以便于大家掌握索引建立的方法。   1、主键就是聚集索引   这种想法笔者认为是极端错误的,是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。   通常,我们会在每个表中都建立一个ID列,以区分每条数据,并且这个ID列是自动增大的,步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时,如果我们将这个列设为主键,SQL ...
(一)深入浅出理解索引结构   实际上,您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引、簇集索引)和非聚集索引(nonclustered index,也称非聚类索引、非簇集索引)。下面,我们举例来说明一下聚集索引和非聚集索引的区别:   其实,我们的汉语字典的正文本身就是一个聚集索引。比如,我们要查“安”字,就会很自然地翻开字典的前几页,因为“安”的拼音是“an”,而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的,那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不 ...
      相信越来越多的web开发者,在持久层都采用了hibernate。都说hibernate效率高,可是当整个项目下来后发现,比其他持久层版本慢很多,当然功能也多很多。记得当初同事测试hibernate销率时,在100万数据量的情况下,hibernate的效率几乎接近于jdbc,那么为什么如今很多公司的项目运行那么慢呢(不仅仅是hibernate),也许有些细节上的东西我们开发人员没有注意。    就拿hibernate来说吧,他支持hql查询,在我们组装sql语句时,需要注意2个问题:   1、要查询当然离不开数据库,我们建表时,默认的主键都是索引,这里要注意的就是关于建立单个索引 ...
出处:http://www.regexlab.com/zh/regref.htm 引言     正则表达式(regular expression)就是用一个“字符串”来描述一个特征,然后去验证另一个“字符串”是否符合这个特征。比如 表达式“ab+” 描述的特征是“一个 'a' 和 任意个 'b' ”,那么 'ab', 'abb', 'abbbbbbbbbb' 都符合这个特征。   正则表达式可以用来:(1)验证字符串是否符合指定特征,比如验证是否是合法的邮件地址。(2)用来查找字符串,从一个长的文本中查找符合指定特征的字符串,比查找固定字符串更加灵活方便。(3)用来替换,比普通的替换更强 ...
    数据库索引是为了增加查询速度而对表字段附加的一种标识。见过很多人机械的理解索引的概念,认为增加索引只有好处没有坏处。这里想把之前的索引学习笔记总结一下:     首先明白为什么索引会增加速度,DB在执行一条Sql语句的时候,默认的方式是根据搜索条件进行全表扫描,遇到匹配条件的就加入搜索结果集合。如果我们对某一字段增加索引,查询时就会先去索引列表中一次定位到特定值的行数,大大减少遍历匹配的行数,所以能明显增加查询的速度。那么在任何时候都应该加索引么?这里有几个反例: 1、如果每次都需要取到所有表记录,无论如何都必须进行全表扫描了,那么是否加索引也没有意义了。 2、对非唯一的字 ...
一、引言 对数据库索引的关注从未淡出我的们的讨论,那么数据库索引是什么样的?聚集索引与非聚集索引有什么不同?希望本文对各位同仁有一定的帮助。有不少存疑的地方,诚心希望各位不吝赐教指正,共同进步。[最近首页之争沸沸扬扬,也不知道这个放在这合适么,苦劳?功劳?……]     二、B-Tree 我们常见的数据库系统,其索引使用的数据结构多是
海量数据(百万以上),其中有些全部字段都相同,有些部分字段相同,怎样高效去除重复? 如果要删除手机(mobilePhone),电话(officePhone),邮件(email)同时都相同的数据,以前一直使用这条语句进行去重: delete from 表 where id not i ...
Global site tag (gtag.js) - Google Analytics