七叶笔记 » 数据库 » postgresql 中position函数的性能详解

postgresql 中position函数的性能详解

本来以为事情完美解决,但是性能的差距却让人感觉很失望,如下图

数据库原生的“position”和自己提供“lastindexof”,居然产生了30倍以上的性能差距,那么探究缘由就变成一个有意思的事情。也算第一次尝试翻阅数据库源码,中间总是有点小麻烦,不过当我找到如下代码的时候,那种恍然大悟的欣喜也算满足了自己求知欲。

注意看1054行,运用了指针~ 可见数据库底层运算,用了引用传递,而我自己写的函数是一个拷贝传递。

原因找到了,解决问题也就手到擒来,拿C写一个扩展?或者?

本可以拿C写一些底层代码练练手,不过那又需要重新编译等等,时间有限,留给以后去做吧,先想个简单的办法去解决它。

解决方法如下

测试性能截图

好吧,虽然由于函数的复杂性增加,性能还是慢了一倍多,但是比起之前5s之久还是快了不少。

tips:

最近得到德哥的回答,引用传递可以使用游标类型!再次谢谢德哥~

补充: SQL之查询函数LOCATE、POSITION、INSTR、FIND_IN_SET、IN、LIKE

LOCATE()

返回要查询的字符串在被查询字符串里第一次出现的位置

注:当在 MySQL 4.0 中时,如有任一参数是一个二进制字符串,它才是字母大小写敏感的

LOCATE(substr,str)

返回substr字符串在str里第一次出现的位置,没有返回0

LOCATE(substr,str,pos)

返回substr字符串在str里pos(起始位置)出现的位置,没有返回0

注:pos必须大于第一次出现的位置,才能显示第二次出现的位置

POSITION()

返回要查询的字符串在被查询字符串里第一次出现的位置(和locate用法一样,查了很多资料position是locate的别名)

POSITION(substr IN str)

返回substr字符串在str出现的位置,没有返回0

INSTR()

返回要查询的字符串在被查询字符串里第一次出现的位置。这和LOCATE()的双参数形式相同,只是参数的顺序被颠倒。

INSTR(str,substr)

返回substr字符串在str出现的位置,没有返回0

FIND_IN_SET()

返回在集合中的索引位置(竖向发展)

FIND_IN_SET(str,strlist)

返回str1在strlist集合中的索引位置

IN()

返回在集合中的索引位置(同FIND_IN_SET)

str IN (strlist)

返回str1在strlist集合中的索引位置

LIKE

返回类似(模糊)字符的集合

LIKE %str%

返回以str类似的集合

以上为个人经验,希望能给大家一个参考,也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方,望不吝赐教。

相关文章