忙了一阵子，今天用空下来的一点时间来总结一下之前未完成的分词系列吧。。

　　上篇提到了使用HashSet<T>作为词典存储数据结构的方法，这也是在不使用数据库的情况下，自己在能力范围之内找到的最佳的解决方案。

　　但是，如果使用数据库呢，好吧，下面就让我们来看在使用数据库的情况下，本分词软件的表现。

　一、建立数据库

　　随后我们不作任何优化措施，直接开始简单的测试，首先开启SQL中显示统计信息和分析、编译、执行各语句耗时的功能：

　　来看一下查询“他们”这个简单的词，select * from Vocabulary where item = ‘他们’

　　SQL中的执行结果：

　　没错，100字的文本分词时间居然达到了20+秒，无法忍受的一个结果。

　二、优化第一步——建立索引

　　索引的文章园子里面有很多，从原理到实例都有些经典的，这里自不必多说，这里主要看一下索引在本分词软件中的应用。

　　首先，我们频繁使用item字段，也就是保存词的字段进行查询，且其是表的主键，很适合建立聚集索引：

　　好了，建立完成后来看一下最终的结果：

　三、优化第二步——使用填充因子

　填充因子百分比指首次创建索引时索引页的叶级别充满程序，若没有显示设置，则默认为0。

　　当最初生成索引时，SQL Server 将索引 B 树结构放置在连续的物理页上，以便通过连续 I/O 扫描索引页获取最佳 I/O 性能。当由于发生页拆分，需要将新的页插入索引的逻辑 B 树结构时，SQL Server 必须分配新的 8 KB 索引页。这种插入发生在硬盘上的其它位置，从而打断了索引页的物理连续特性。使 I/O 操作从连续变为不连续，从而使得性能减低一半。可以通过重建索引页以恢复索引页的物理连续顺序来解决过多的页拆分。聚集索引的叶级也会遇到相同的问题，从而影响表的数据页。

　　100%填充因子可以提升读取的性能，但会减缓写活动的功能，引发频繁的页拆分，因为数据库引擎为了在数据页中得到空间必须持续地交换行的位置。

填充因子太低会给插入带来便利，但读取较慢，因为如果填充因子太小 , 就需要使用更多的页来保存数据，而更多页就意味着每个查询要读取的物理数据页读操作的数量也变得更多，此时，读和写操作的机能都会降低。

最佳实践：在没有修改活动的表中使用100%的填充因子，中低活动的使用70-90%，高活动的使用50%甚至更低的填充因子。

　　上面的代码演示了创建聚集索引并指定100%的填充因子。

　　继续看一下数据库中查询“他们”的效果：

　　可以看到，1000字的文本仅仅花了1.7秒左右，较之前没有使用索引的惨不忍睹有了不少好转。

　四、优化第三步——使用存储过程

　首先，列举一下公认的存储过程的几个优点：

　　span style=”color:#FF0000;font-weight:bold;”>高效：

–存储过程只在建立时编译，以后每次执行就不需要重新编译，而一般SQL语句每执行一次都需要先分析，然后再执行，所以使用存储过程可提高SQL语句的执行效率。 –存储过程代码直接存储于数据库中，不会产生大量T-sql语句的代码流量，显著降低了 络流量。 　　span style=”color:#FF0000;font-weight:bold;”>安全：存储过程执行时，使用的是参数化的SQL语句，防止了常见的如SQL注入攻击等。 　　span style=”color:#FF0000;font-weight:bold;”>可复用，可维护性高：更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。 　  由于分词过程中需要大量重复的执行SQL语句，那到底使用存储过程对于执行效率有没有提高呢，那我们一试：

程序中详细调用步骤：

再次对1000字的文本进行测试，时间有小幅提升，大致在1.3秒左右，较之前有25%左右的性能提升。

　五、总结

至此算是完成了本分词软件的所有研究，进行一个总结示例如下（其中V5.0和V6.0合并在上篇一起讲了）：

　　不过这还木有完结，下篇将是最后一篇，讲述本分词软件移植BS时的最后展示效果。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表31294 人正在系统学习中 相关资源：jFB精良分班软件绿色版-教育工具类资源-CSDN文库