写于：2002/08 最后更新： 11/29/2006 17:23:30
Feed Back >> (Read this before you ask question)
<广告>

版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://www.chedong.com/tech/lucene.html

关键词：Lucene java full-text search engine Chinese word segment

内容摘要：

Lucene是一个基于Java的全文索引工具包。

1. 基于Java的全文索引引擎Lucene简介：关于作者和Lucene的历史
2. 全文检索的实现：Luene全文索引和数据库索引的比较
3. 中文切分词机制简介：基于词库和自动切分词算法的比较
4. 具体的安装和使用简介：系统结构介绍和演示
5. Hacking Lucene：简化的查询分析器，删除的实现，定制的排序，应用接口的扩展
6. 从Lucene我们还可以学到什么

基于Java的全文索引/检索引擎——Lucene

Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。

Lucene的发展历程：早先发布在作者自己的www.lucene.com，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：http://jakarta.apache.org/lucene/

已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有：

• J ive：WEB论坛系统；
• Eyebrows：邮件列表HTML归档/浏览/查询系统，本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系统的主要开发者之一，而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。
• Cocoon:基于XML的web发布框架，全文检索部分使用了Lucene

• Eclipse:基于Java的开放开发平台，帮助部分的全文索引使用了Lucene

对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索的实现机制

Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。

比较一下Lucene和数据库：

索引数据源：doc(field1,field2...) doc(field1,field2...)
                  \  indexer /
                 _____________
                | Lucene Index|
                --------------
                 / searcher \
 结果输出：Hits(doc(field1,field2) doc(field1...))

 索引数据源：record(field1,field2...) record(field1..)
              \  SQL: insert/
               _____________
              | DB  Index   |
               -------------
              / SQL: select \
结果输出：results(record(field1,field2..) record(field1...))

全文检索 ≠ like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。

由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。

由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。

可以通过一下表格对比一下数据库的模糊查询：

全文检索和数据库应用最大的不同在于：让 最相关的 头100条结果满足98%以上用户的需求

Lucene的创新之处：

大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。

Lucene和其他一些全文检索系统/应用的比较：

关于亚洲语言的的切分词问题(Word Segment)

对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。

首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。

但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？
“北京 天安门” 还是“北 京 天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。

另外一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，比如：
"北京天安门" ==> "北京 京天 天安 安门"。

这样，在查询的时候，无论是查询"北京" 还是查询"天安门"，将查询词组按同样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言：韩文，日文都是通用的。

基于自动切分的最大优点是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来说，基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多，而对于英文，索引文件一般只有原文件的30%-40%不同，

目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法，大家可以在Google查关键词"wordsegment search"能找到更多相关的资料。

安装和使用

下载：http://jakarta.apache.org/lucene/

注意：Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，纯Java的词法分析生成器），所以如果从源代码编译或需要修改其中的QueryParser、定制自己的词法分析器，还需要从https://javacc.dev.java.net/下载javacc。

lucene的组成结构：对于外部应用来说索引模块(index)和检索模块(search)是主要的外部应用入口

简单的例子演示一下Lucene的使用方法：

public class IndexFiles { 
  //使用方法：: IndexFiles [索引输出目录] [索引的文件列表] ... 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0];
    IndexWriter writer;
    //用指定的语言分析器构造一个新的写索引器（第3个参数表示是否为追加索引）
    writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);

    for (int i=1; i<args.length; i++) {
      System.out.println("Indexing file " + args[i]);
      InputStream is = new FileInputStream(args[i]);

      //构造包含2个字段Field的Document对象
      //一个是路径path字段，不索引，只存储
      //一个是内容body字段，进行全文索引，并存储
      Document doc = new Document();
      doc.add(Field.UnIndexed("path", args[i]));
      doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
      //将文档写入索引
      writer.addDocument(doc);
      is.close();
    };
    //关闭写索引器
    writer.close();
  }
}
　

索引过程中可以看到：

• 语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的，虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser，这2个分析器缺省都不支持中文，所以要加入对中文语言的切分规则，需要修改这2个分析器。
• Lucene并没有规定数据源的格式，而只提供了一个通用的结构（Document对象）来接受索引的输入，因此输入的数据源可以是：数据库，WORD文档，PDF文档，HTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象即可进行索引。
• 对于大批量的数据索引，还可以通过调整IndexerWrite的文件合并频率属性（mergeFactor）来提高批量索引的效率。

检索过程和结果显示：

搜索结果返回的是Hits对象，可以通过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索，可以将查询结果的path字段和相应查询的匹配度(score)打印出来，

public class Search { 
  public static void main(String[] args) throws Exception {
    String indexPath = args[0], queryString = args[1];
    //指向索引目录的搜索器
    Searcher searcher = new IndexSearcher(indexPath);
    //查询解析器：使用和索引同样的语言分析器
    Query query = QueryParser.parse(queryString, "body", 
                              new SimpleAnalyzer());
    //搜索结果使用Hits存储
    Hits hits = searcher.search(query);
    //通过hits可以访问到相应字段的数据和查询的匹配度
    for (int i=0; i<hits.length(); i++) {
      System.out.println(hits.doc(i).get("path") + "; Score: " + 
                         hits.score(i));
    };
  }
}

Hacking Lucene

简化的查询分析器

个人感觉lucene成为JAKARTA项目后，画在了太多的时间用于调试日趋复杂QueryParser，而其中大部分是大多数用户并不很熟悉的，目前LUCENE支持的语法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")

中间的逻辑包括：and or + - &&||等符号，而且还有"短语查询"和针对西文的前缀/模糊查询等，个人感觉对于一般应用来说，这些功能有一些华而不实，其实能够实现目前类似于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择。

添加修改删除指定记录（Document）

Lucene提供了索引的扩展机制，因此索引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另建索引，然后利用IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。

根据某个字段值的排序功能

lucene缺省是按照自己的相关度算法（score）进行结果排序的，但能够根据其他字段进行结果排序是一个在LUCENE的开发邮件列表中经常提到的问题，很多原先基于数据库应用都需要除了基于匹配度（score）以外的排序功能。而从全文检索的原理我们可以了解到，任何不基于索引的搜索过程效率都会导致效率非常的低，如果基于其他字段的排序需要在搜索过程中访问存储字段，速度回大大降低，因此非常是不可取的。

但这里也有一个折中的解决方法：在搜索过程中能够影响排序结果的只有索引中已经存储的docID和score这2个参数，所以，基于score以外的排序，其实可以通过将数据源预先排好序，然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程中访问不在索引中的某个字段值。

这里需要修改的是IndexSearcher中的HitCollector过程：

...
　scorer.score(new HitCollector() {
	private float minScore = 0.0f;
	public final void collect(int doc, float score) {
	  if (score > 0.0f &&			  // ignore zeroed buckets
	      (bits==null || bits.get(doc))) {	  // skip docs not in bits
	    totalHits[0]++;
	    if (score >= minScore) {
              /* 原先：Lucene将docID和相应的匹配度score例入结果命中列表中：
	       * hq.put(new ScoreDoc(doc, score));	  // update hit queue
               * 如果用doc 或 1/doc 代替 score，就实现了根据docID顺排或逆排
               * 假设数据源索引时已经按照某个字段排好了序，而结果根据docID排序也就实现了
               * 针对某个字段的排序，甚至可以实现更复杂的score和docID的拟合。
               */
              hq.put(new ScoreDoc(doc, (float) 1/doc )); 
	      if (hq.size() > nDocs) {		  // if hit queue overfull
		hq.pop();			  // remove lowest in hit queue
		minScore = ((ScoreDoc)hq.top()).score; // reset minScore
	      }
	    }
	  }
	}
      }, reader.maxDoc());

更通用的输入输出接口

虽然lucene没有定义一个确定的输入文档格式，但越来越多的人想到使用一个标准的中间格式作为Lucene的数据导入接口，然后其他数据，比如PDF只需要通过解析器转换成标准的中间格式就可以进行数据索引了。这个中间格式主要以XML为主，类似实现已经不下4，5个：

数据源: WORD       PDF     HTML    DB       other
         \          |       |      |         /
                       XML中间格式
                            |
                     Lucene INDEX

目前还没有针对MSWord文档的解析器，因为Word文档和基于ASCII的RTF文档不同，需要使用COM对象机制解析。这个是我在Google上查的相关资料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文档转换成text：http://www.winfield.demon.nl/index.html

索引过程优化

索引一般分2种情况，一种是小批量的索引扩展，一种是大批量的索引重建。在索引过程中，并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作（文件I/O是一件非常消耗资源的事情）。

Lucene先在内存中进行索引操作，并根据一定的批量进行文件的写入。这个批次的间隔越大，文件的写入次数越少，但占用内存会很多。反之占用内存少，但文件IO操作频繁，索引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。根据我的使用经验：缺省Indexer是每20条记录索引后写入一次，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左右。

搜索过程优化

lucene支持内存索引：这样的搜索比基于文件的I/O有数量级的速度提升。
http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。

Lucene面向全文检索的优化在于首次索引检索后，并不把所有的记录（Document）具体内容读取出来，而起只将所有结果中匹配度最高的头100条结果（TopDocs）的ID放到结果集缓存中并返回，这里可以比较一下数据库检索：如果是一个10,000条的数据库检索结果集，数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多，Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是用不到这么多的结果的，头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存，并再重新向后抓取。所以如果构造一个Searcher去查1－120条结果，Searcher其实是进行了2次搜索过程：头100条取完后，缓存结果用完，Searcher重新检索再构造一个200条的结果缓存，依此类推，400条缓存，800条缓存。由于每次Searcher对象消失后，这些缓存也访问那不到了，你有可能想将结果记录缓存下来，缓存数尽量保证在100以下以充分利用首次的结果缓存，不让Lucene浪费多次检索，而且可以分级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。

我的一些尝试：

• 支持中文的Tokenizer：这里有2个版本，一个是通过JavaCC生成的，对CJK部分按一个字符一个TOKEN索引，另外一个是从SimpleTokenizer改写的，对英文支持数字和字母TOKEN，对中文按迭代索引。
• 基于XML数据源的索引器：XMLIndexer，因此所有数据源只要能够按照DTD转换成指定的XML，就可以用XMLIndxer进行索引了。
• 根据某个字段排序：按记录索引顺序排序结果的搜索器：IndexOrderSearcher，因此如果需要让搜索结果根据某个字段排序，可以让数据源先按某个字段排好序（比如：PriceField），这样索引后，然后在利用这个按记录的ID顺序检索的搜索器，结果就是相当于是那个字段排序的结果了。

从Lucene学到更多

Luene的确是一个面对对象设计的典范

• 所有的问题都通过一个额外抽象层来方便以后的扩展和重用：你可以通过重新实现来达到自己的目的，而对其他模块而不需要；
• 简单的应用入口Searcher, Indexer，并调用底层一系列组件协同的完成搜索任务；
• 所有的对象的任务都非常专一：比如搜索过程：QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),通过底层的索引读取结构IndexReader进行索引的读取，并用相应的打分器给搜索结果进行打分/排序等。所有的功能模块原子化程度非常高，因此可以通过重新实现而不需要修改其他模块。 
• 除了灵活的应用接口设计，Lucene还提供了一些适合大多数应用的语言分析器实现（SimpleAnalyser,StandardAnalyser），这也是新用户能够很快上手的重要原因之一。

这些优点都是非常值得在以后的开发中学习借鉴的。作为一个通用工具包，Lunece的确给予了需要将全文检索功能嵌入到应用中的开发者很多的便利。

此外，通过对Lucene的学习和使用，我也更深刻地理解了为什么很多数据库优化设计中要求，比如：

• 尽可能对字段进行索引来提高查询速度，但过多的索引会对数据库表的更新操作变慢，而对结果过多的排序条件，实际上往往也是性能的杀手之一。
• 很多商业数据库对大批量的数据插入操作会提供一些优化参数，这个作用和索引器的merge_factor的作用是类似的，
• 20%/80%原则：查的结果多并不等于质量好，尤其对于返回结果集很大，如何优化这头几十条结果的质量往往才是最重要的。
• 尽可能让应用从数据库中获得比较小的结果集，因为即使对于大型数据库，对结果集的随机访问也是一个非常消耗资源的操作。
  

参考资料：

Apache: Lucene Project
http://jakarta.apache.org/lucene/
Lucene开发/用户邮件列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org

The Lucene search engine: Powerful, flexible, and free
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html

Lucene Tutorial
http://www.darksleep.com/puff/lucene/lucene.html

Notes on distributed searching with Lucene
http://home.clara.net/markharwood/lucene/

中文语言的切分词
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment

搜索引擎工具介绍
http://searchtools.com/

Lucene作者Cutting的几篇论文和专利
http://lucene.sourceforge.net/publications.html 

Lucene的.NET实现：dotLucene
http://sourceforge.net/projects/dotlucene/

Lucene作者Cutting的另外一个项目：基于Java的搜索引擎Nutch
http://www.nutch.org/   http://sourceforge.net/projects/nutch/

关于基于词表和N-Gram的切分词比较
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html

2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座：非常详细的Lucene架构解说

特别感谢：
前网易CTO许良杰(Jack Xu)给我的指导：是您将我带入了搜索引擎这个行业。

关于索引，推荐转载的这篇文章
http://blog.csdn.net/dutguoyi/archive/2006/01/10/575617.aspx

改善SQL语句的效率
http://community.csdn.net/Expert/topic/5087/5087396.xml?temp=.345669
数据量很大怎样加快索检速度
http://community.csdn.net/Expert/topic/5058/5058320.xml?temp=.1229517
索引建立方法的区别
http://community.csdn.net/Expert/topic/5068/5068154.xml?temp=.3010218
频繁插入删除数据需要更新索引
http://community.csdn.net/Expert/topic/4937/4937910.xml?temp=.8428614
测试了一下sql server 2005 全文检索
http://community.csdn.net/Expert/topic/4878/4878430.xml?temp=.6049311

其他关于效率的高频问题

判断一个表的数据不在另一个表中最优秀方法？
http://community.csdn.net/Expert/topic/5038/5038742.xml?temp=.4704553
删除千万级表中重复记录的办法
http://community.csdn.net/Expert/topic/5089/5089261.xml?temp=.7907068

数据库数据查询变得不正常类型问题

大数据量，稳定运行一段时候以后无法得到查询结果。
http://community.csdn.net/Expert/topic/4810/4810464.xml?temp=9.014529E-02

from: http://www.blogjava.net/zqli/archive/2006/12/08/86391.html

Type:  copyright for distribution terms
　       h for help with SQL commands
　       ? for help with psql commands
　       g or terminate with semicolon to execute query
　       q to quit
house=#
输入encoding GBK
house=#set encoding GBK
然后就可以插入汉字了。

from: http://publish.it168.com/2006/0219/20060219173801.shtml?positioncode=1547

　　现在几乎所有的应用系统都无法避免使用数据库系统。在JAVA世界里访问数据库是一件非常轻松的事情，JDBC为JAVA应用程序访问数据库提供了一个统一的接口，通过使用JDBC接口开发者无需关心系统最终采用哪种数据库，因为JDBC仅仅是定义了访问几个JAVA的接口类，具体的实现是由数据库厂商提供的，这种做法其实与其他数据库连接方式例如ODBC是类似的。但是在实际的应用过程中，开发者发现离JDBC设计的初衷还是有一定距离，就比如说在存储字符串时的编码问题，我想很多开发者都会遇见这个问题，倒不是因为说解决它有什么技术方面的难度，而是它的的确确非常繁琐。我们必须在每次写入或者读出字符串的时候进行编码和反编码处理；或者说我们可以写一个方法可以进行编码处理的，但又必须在每次数据库操作的时候调用，虽然调用很简单，可是我非得这样吗？要是忘了编码那又要DEBUG了。当然你可能觉得这并没有什么，或者你可能很勤快，喜欢写大量重复的代码，可是你难道没有觉得这种繁琐的工作正在浪费你过于宝贵的青春吗？停止你的键盘输入，让我们来解决这个问题吧！

　　解决思路

　　在传统的应用程序中数据库操作部分我们可以想象成两层，如图所示：一个是数据库的"连接池"，另外一个业务数据操作层。在这里数据库的连接池是广义的，你可以把JDBC中的DriverManager也当成是连接池，具体的意思就是我们可以通过这层来获取到指定数据库的连接而不去关心它是怎么获取的。如果这个时候数据库系统（有如Informix，SQL Server）要求对字符串进行转码才能存储（例如最常见的GBK->ISO8859_1转码），那我们就必须在业务数据操作层来进行，这样有多少业务数据操作我们就要做多少编码转码的工作，太麻烦了，代码中充斥中大量重复的内容。本文提出的解决方案就是利用对获取到的数据库连接实例进行二次封装，也就是在数据库连接池与业务数据操作层之间加入了连接封装层，当然了，我们也完全可以直接将连接封装集成到数据库连接池内部。关于连接池的实现请参照我的另外一篇文章《使用JAVA动态代理实现数据库连接池》

图一

　　我们知道进行编码和转码工作都是集中在JDBC的两个接口PreparedStatement和ResultSet上进行的，主要涉及PreparedStatement的setString方法以及ResultSet的getString方法。前面我们讲过需要加入一个连接封装层来对数据库连接实例进行二次封装，但是怎么通过这个封装来改变PreparedStatement和ResultSet这两个接口的行为呢？这个问题其实也很简单，因为PreparedStatement接口必须通过Connection接口来获取实例，而ResultSet接口又必须从Statement或者PreparedStatement接口来获取实例，有了这样的级联关系，问题也就迎刃而解了。还是利用我在文章《使用JAVA动态代理实现数据库连接池》中使用的动态接口代理技术。首先我们设计Connection接口的代理类_Connection，这个代理类接管了Connection接口中所有可能获取到Statement或者PreparedStatement接口实例的方法，例如：prepareStatement和createStatement。改变这两个方法使之返回的是经过接管后的Statement或者PreparedStatement实例。通过对于Statement接口也有相应的代理类_Statement，这个代理类接管用于获取ResultSet接口实例的所有方法，包括对setString方法的接管以决定是否对字符串进行编码处理。对于接口ResultSet的接管类_ResultSet就相应的比较简单，它只需要处理getString方法即可。

　　关键代码

　　前面我们大概介绍了这个解决方案的思路，下面我们给出关键的实现代码包括Connection的代理类，Statement的代理类，ResultSet的代理类。这些代码是在原来关于数据库连接池实现的基础上进行扩充使之增加对自动编码处理的功能。有需要源码打包的可以通过电子邮件跟我联系。

_Connection.java

/*
 * Created on 2003-10-23 by Liudong
 */
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/*
 *
 * 数据库连接的代理类
 * @author Liudong
 */
 class _Connection implements InvocationHandler{
 private Connection conn = null;
 private boolean coding = false;
 //指定是否进行字符串转码操作
 _Connection(Connection conn, boolean coding){
  this.conn = conn;
  this.coding = coding;
  initConnectionParam(this.conn);
 
 }
 
 /** 
  * Returns the conn. 
  * @return Connection 
  */
 
 public Connection getConnection() {
  Class[] interfaces = conn.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = Connection.class;
  
  }
 
  Connection conn2 = (Connection)Proxy.newProxyInstance( conn.getClass().getClassLoader(), interfaces,this);
  return conn2;
 
 }
 
 /** 
  * @see java.lang.reflect.InvocationHandler#invoke 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  //调用相应的操作
  Object obj = null;
  try{
   obj = m.invoke(conn, args);
   //接管用于获取语句句柄实例的方法
   if((CS.equals(method)||PS.equals(method))&&coding)
    return new _Statement((Statement)obj,true).getStatement();
  
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
  }
  return obj;
 }
 
 private final static String PS = "prepareStatement";
 private final static String CS = "createStatement";
}

_Statement.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/**
 * 数据库语句对象实例的代理类
 * @author Liudong
 */
class _Statement implements InvocationHandler{ 
 private Statement statement ; //保存所接管对象的实例 
 private boolean decode = false; //指定是否进行字符串转码 

 public _Statement(Statement stmt,boolean decode) { 
  this.statement = stmt;
  this.decode = decode;
 }
 
 /** 
  * 获取一个接管后的对象实例 
  * @return 
  */
 public Statement getStatement() {
  Class[] interfaces = statement.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){ 
   interfaces = new Class[1];
   interfaces[0] = Statement.class;
  } 
  Statement stmt = (Statement)Proxy.newProxyInstance(   
   statement.getClass().getClassLoader(), 
   interfaces,this);
  return stmt;
 
 }
 
 /** 
  * 方法接管 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
  String method = m.getName(); //接管setString方法 
  if(decode && SETSTRING.equals(method)) {
   try{
    String param = (String)args[1];
    if(param!=null)
     param = new String(param.getBytes(),"8859_1");
    return m.invoke(statement,new Object[]{args[0],param});
   } catch(InvocationTargetException e){
    throw e.getTargetException();
        
   }  
  }
  
  //接管executeQuery方法
  
  if(decode && EXECUTEQUERY.equals(method)){
   try{
    ResultSet rs = (ResultSet)m.invoke(statement,args);
    return new _ResultSet(rs,decode).getResultSet();
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }  
  }
  
  try{
   return m.invoke(statement, args);
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
   } 
 }
 //两个要接管的方法名
 
 private final static String SETSTRING = "setString";
 private final static String EXECUTEQUERY = "executeQuery";
}

_ResultSet.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.ResultSet;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * 数据库结果集的代理类
 * @author Liudong
 */
 class _ResultSet implements InvocationHandler{ 
 private ResultSet rs = null;
 private boolean decode = false;
 
 public _ResultSet(ResultSet rs,boolean decode) {
  this.rs = rs;
  this.decode = decode;
 }
 
 public ResultSet getResultSet(){ 
  Class[] interfaces = rs.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = ResultSet.class;  
  }
 
  ResultSet rs2 = (ResultSet)Proxy.newProxyInstance(rs.getClass().getClassLoader(),interfaces,this);
  return rs2;
 
 }

 /** 
  * 结果getString方法 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  if(decode && GETSTRING.equals(method)){
   try{
    String result = (String)m.invoke(rs,args);
    if(result!=null)     
     return new String(result.getBytes("8859_1"));
    return null;
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }
   
  } 
  
  try{
   return m.invoke(rs, args);
  }catch(InvocationTargetException e){
   throw e.getTargetException();
  }
 }
 
 private final static String GETSTRING = "getString";

}

　　现在我们已经把三个接口的代理类做好了，下一步就是怎么来使用这三个类。其实对于使用者来讲并不需要关心三个类，只需要了解_Connection就可以了，因为另外两个是_Connection直接调用的。为了使用_Connection我们必须传入两个参数，第一个是数据库实际的数据库连接实例，另外一个是布尔值代表是否进行转码处理。我们必须先通过实际的情况获取到数据库连接后再传入_Connection的构造函数作为参数，下面例子告诉你如何来使用_Connection这个类：

　　Connection conn = getConnection(); //获取数据库连接
　　boolean coding = false; //从配置或者其他地方读取是否进行转码的配置 
　　//接管数据库连接实例 
　　_Connection _conn = new _Connection(conn,coding);
　　//获得接管后的数据库连接实例，以后直接使用conn2而不是conn 
　　Connection conn2 = _conn.getConnection();

　　因为对一个应用系统来讲，数据库连接的获取必然有统一的方法，在这个方法中加入对连接的接管就可以一劳永逸的解决数据库的编码问题。

　　性能比较

　　功能没有问题了，开发者接下来就会关心性能的问题，因为在进行一些对响应速度要求很高或者大数据量的处理情况下性能就成为一个非常突出的问题。由于JAVA中的动态接口代理采用的是反射（Reflection）机制，同时又加入我们自己的一些代码例如方法名判断，字符串转码等操作因此在性能上肯定比不上直接使用没有经过接管的数据库连接。但是这点性能上的差别是不是我们可以忍受的呢，为此我做了一个试验对二者进行了比较：

　　测试环境简单描述：

　　使用ACCESS数据库，建两张结构一样的表，计算从获取连接后到插入数据完毕后的时间差，两个程序（直连数据库和使用连接接管）都进行的字符串的转码操作。

　　测试结果：

　　从上面这张测试结果表中来看，二者的性能的差别非常小，尽管在两万条数据的批量插入的时候时间差别也不会多于一秒钟，这样的结果应该说还是令人满意的，毕竟为了程序良好的结构有时候牺牲一点点性能还是值得的。

　　本文算是我之前文章《使用JAVA动态代理实现数据库连接池》中提出的数据库连接池实现的进一步完善，同样使用动态接口代理的技术来解决数据库编码的问题。JAVA的这个高级技术可以用来解决许多实际中非常棘手的问题，就像本文提到的编码问题的处理以及数据库连接池的实现，同时在WEB开发框架的实现上也有非常大的作为。欢迎对这方面感兴趣的朋友来信共同来研究。

from: http://www.javafan.net/article/20041212111952983.html

l         为应用选择最好最快的 JDBC 驱动 ,参考本站文章 。 JDBC3.0提供了新的特性来提高性能，诸如连接池， statemente池的改进  

l        对数据库使用连接池并且重用连接，而不要重复打开和关闭连接。最佳的连接池大小是当连接池大到足够使服务请求不等待

l         尽量使用支持 JDBC3.0 的驱动，因为 JDBC3.0 支持包括 DataSource 对象，连接池，分布式事务支持， RowSets 和 prepared statement 池等性能增强特性

l         Prepared statement 池（自从 JDBC3.0 开始有）高速缓存已经预先优化并运行了的 SQL 查询，这样，他们被再次请求的时候，不必经历再次的优化预处理（避免最优化步骤，诸如检查语法，验证地址，优化访问路径和执行计划）。 Statement 池是一个很好的，重要的性能优化方法

l         JDBC3.0 中的 Statement 池和连接池能合作共享 statement 池，这样，能使用一个已高速缓存的 statement （该 statement 来自另外一个连接）的连接，在由任一连接执行的 一些SQL 首次被执行时，产生的 statement 准备开销仅一次

l         RowSet对象与 ResultSet 对象相似，但是能提供当断开连接的时候对数据库数据的访问。这允许数据以它最简单的形式被高效的高速缓存

l         用同一个连接执行多个 statements

l         关闭 autocommit ，但不要让事务打开太久

l         避免将事务分布开（事务跨越多个连接）

l         最小化数据库的行和列数据获取。使用 setMaxRows, setMaxFieldSize,和 SetFetchSize

l         使用最高效的数据类型：字符串比整数型快，整数型比浮点类型和时间戳类型都要高效（是否不太理解^&^，这是针对DB2数据库处理来说的，处理character类型最快，而处理integer类型通常需要一些转换或者字节排序）

l         使用 updateXXX()方法更新： updateXXX() 在可更新的结果集上调用。结果集已经定位到了一行 , 因此当使用一个 UPDATE statement 时，可以消除通常的查找要更新的数据行的开销

l         Cache任何请求的元数据（ metadata ）并尽可能少的使用元数据 方法，其慢的程度一用便知

l         避免在元数据 查询中使用 null 参数

l         使用虚拟查询获得一行的元数据，不要使用getcolumns()（假如应用允许用户使用列数据，应用是使用getColumns来返回列的信息给用户还是准备一个虚拟查询而后调用getMetadata呢？

l         使用存储过程，避免多余的网络传输

l         在存储过程中使用参量，不要将数据挨个地放在statement中，最小化解析开销。此条针对DB2来说，其它数据库未必适用。SQL总是以字符串形式发送给DB2数据库，例如：
CallableStatement cstmt = conn.prepareCall ("call getCustName (12345)");
ResultSet rs = cstmt.executeQuery ();
DB2服务器必须解析该SQL，验证参量类型，并将参量转化为正确的数据类型。

l         对需要重复执行的statement使用预处理statement（PreparedStatement）

l         选择使用最佳游标：对连续读取使用游标；对双向滚动使用游标。对仅返回一行的查询避免使用游标。

l         在JVM中Cache频繁请求的数据，避免不必要的数据库请求

l         采用预读取机制， 批量取行，而不要一次一行 。调整批大小和预取行的数量。避免使用预取 BLOB 数据。

l         除非绝对需要，否则避免移动数据

l         在数据穿过网络之前要使流化数据（ Streamline data ）

l         避免每次处理一行，尽可能一起处理多行。

l         在表中统计个数（例如：使用 select count(*) from myTable,yourTable where …）属于资源密集型的。试试首先选入临时表，仅返回该计数（count），然后发送精确的二次查询获得临时表中的行的子集。

l         恰当的使用 SQL 能减少资源请求。使用返回所需数据的最小值的查询：避免 select * 查询。一个返回小的数据子集的复杂查询，比一个简单的，返回超过所需的大量数据的简单查询更高效。

l         使你的查询尽可能精巧，例如：尽可能精确地最小化要传输的数据，使其是所需的子集

l         努力批量更新：将 statement 收集到一起，然后在一个事务里面一起执行。如果可能，使用有条件的逻辑和临时变量来达到 statement 批处理

l         永远不要让 DBMS 事务跨越用户输入

l         考虑使用乐观锁。乐观锁使用时间戳验证数据是否还没有被其他用户改变，否则事务失败

l         使用 恰当的更新，例如：更新行/表中已经存在的数据，而不要添加或者删除行/表。在适当的位置更新数据要比移动数据快得多，如果更新需要的空间比表设计能提供的更多，这可能是需要的。如果你设计的行需要空间初始化，更新将会更快。交易是你的表可能需要更多的磁盘空间，但可能速度更快。由于磁盘空间是便宜的，使用一点点能提高性能，这应该说是非常有价值的投资

l         分开存储正在操作的数据和历史数据（更一般的情况是将频繁使用的数据和不常使用的数据分开存储）

l         尽可能小的保留你的操作数据集，避免必须读那些不相关的数据

l         DBMS可以很好的并行运转，尽量将应用设计成当和 DBMS交互时应用能做其他事情。

l         使用流水线操作和并行操作。 将应用设计成支持大量并行进程， 使应用运行更快。如果要处理多步，努力设计好应用，以使后来的步骤能够在任何优先的进程已经完成的数据部分上开始工作，而不是必须等到优先进程完成

l       事物的保护级别越高，性能损失就越大。事物级别按增长的顺序为： TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE。使用Connection.setTransactionIsolation() 设置你想要的事物级别

l      默认的自动提交模式由于使每一个数据库命令都成为一个单独的事务，这会严重影响性能，关闭自动提交（Connection.setAutoCommit(false) ），明确声明事务

l         通过整合多个事务为一个的批量操作，并在一个statement中使用Statement.addBatch() 和Statement.executeBatch()

l       Savepoints (from JDBC3.0)需要昂贵的资源。一旦不再需要，就立刻使用Connection.releaseSavepoint()释放掉Savepoints

l         ConnectionPoolDataSource (from JDBC3.0)和PooledConnection接口为连接池提供了built-in支持

l           使用setLogWriter() (from Driver, DataSource, or ConnectionPooledDataSource; from JDBC3.0) 帮助跟踪JDBC流

l           使用Connection.setReadOnly(true)优化只读数据库（操作）交互

l           使用Connection.nativeSQL()察看SQL查询如何在数据库种执行，帮助确保SQL已被优化

l          切记：一旦可能，立刻关闭Statement和ResultSet

l          使用DatabaseMetaData获得数据库功能性信息

l          一直捕捉和处理数据库警告和异常

l          使用最恰当的数据类型明确数据的类型，例如：以date类型存储日期，儿不要用varchar

l          使用可滚动ResultSet (JDBC 2.0)

from: http://www.ijsp.net/2/2003-9/20/0000431.shtml

   CREATE TABLE person ( 
      id   SERIAL, 
      name TEXT 
   );

会自动转换为以下SQL语句：

   CREATE SEQUENCE person_id_seq;
   CREATE TABLE person ( 
      id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
      name TEXT
   );

from: http://www.pgsqldb.org/twiki/bin/view/PgSQL/PostgreFAQ#4.11.1

2. 对一些稍微复杂些的语句, 例如在对金额等敏感数据操作时, 一个常用的操作序列是:
a. 先取出当前金额
b. 运算后得到更新的金额
c. 执行 Update 语句: Update < tableName > set amount= < New amount > where amount= < Old amount >
这种操作是 ORM 不能支持的, SqlMap 能很好的支持。

3. SqlMap 的 Domain 对象可以直接放在业务层, 一般 ORM 的对数据访问的基类要放在数据访问层(因为带有对数据访问的接口, 放在业务层不合适), 增加了代码的冗余度。

4. 用 ORM 的目的是什么, 最主要的目的是减少重复的底层编程工作量, SqlMap 完全可以做到。

再说说 SqlMap 的不足:

1. 因为不象 ORM 那样生成稳定可靠的对数据访问的基类, 所以要对 Map 操作做好充足的单元测试, 增加了测试的工作量。

2. 每次改动数据库, Map 和 Domain 文件往往要手工修改, 因为 SqlMap 的灵活性, 往往我们会手工调整 Map 而不会直接使用 Generator 生成的代码。

from: http://matrix.foresee.cn/blogs/simon/archives/001638.html