字符串匹配性能问题解决方案讨论

目前，1.2版本首先需要解决ORACLE字符串大小写匹配带来的性能问题，那么昨天测试了把TYPE改成NUMBER的确可以大大提高查询效率。非常抱歉，昨天的测试还不够全面，我们还有其他的选择，由于涉及重大，我下面列举了两个方案供大家再次讨论一下：

1. 更改TYPE类型为NUMBER类型

做法：把SCHEMA中所有的TYPE类型以及主键中的字符串类型改成NUMBER，同时用一张表来进行取值范围的说明

涉及范围：Hibernate，JDBC SQL，JSP，TBL，TRG，Upgrade Scripts，Migration，LoadRunner等

与目前系统的比较：

ORIGINAL				TO NUMBER
BIND COST	NOBIND COST	FIRST	N	BIND COST	NOBIND COST	FIRST	N
176	464	4.062	0.734	172	235	2.734	0.094

优点：数据库设计更隐蔽，速度可能更快

缺点：工作量巨大，不能解决支持9i的问题，客户必须使用10.2.0.3的高版本

2. 不更改类型，去掉NLS_SORT

做法：把SCHEMA中我们内部使用的TYPE字段的相关INDEX中的NLS_SORT去掉，确认相关JAVA代码的比较完全匹配，取消ALTER SESSION NLS_COMP | NLS_SORT两个参数，用户输入的不需要区分大小写的字段，需要在相关JAVA代码和INDEX添加UPPER函数。

涉及范围：Hibernate，JDBC SQL，TBL（INDEX）

与目前系统的比较：

ORIGINAL				TO NUMBER
BIND COST	NOBIND COST	FIRST	N	BIND COST	NOBIND COST	FIRST	N
199	486	3.203	0.703	272	559	2.625	0.031

优点：工作量小，10.2.0.1甚至9i

缺点：内部字符串比较需要多注意大小写的问题，可能MSSQL的Index和Oracle不同步，因为MSSQL不需要UPPER索引

注：两个方案的性能比较图表是一个大概的参考，因为每次分析SCHEMA可能带来一定的差异，不过，可以充分说明的是直接使用字符串也不慢，性能的问题在于NLS_SORT参数。

另外，为了更加准确的验证第二套方案，我想请TOM帮忙做一个LoadRunner测试，统计去掉NLS_SORT和Change Index前后性能的差异，不过由于JAVA代码中可能存在比较的不匹配，所以这个测试只能成功执行一部分页面，不过管中窥豹，可见一斑。测试结果下午应该可以出来，到时候请大家讨论一下。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10662397/viewspace-930038/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10662397/viewspace-930038/