搜索
查看: 1354|: 0

Oracle模糊查询方法

[复制链接]

134

主题

2

回帖

528

积分

高级会员

积分
528
发表于 2014-10-13 17:23:50 | 显示全部楼层 |阅读模式
在这个信息量剧增的时代,如何帮助用户从海量数据中检索到想要的数据,模糊查询是必不可少的。那么在Oracle中模糊查询是如何实现的呢?

一、我们可以在where子句中使用like关键字来达到Oracle模糊查询的效果;在Where子句中,可以对datetime、char、varchar字段类型的列用Like关键字配合通配符来实现模糊查询,以下是可使用的通配符:
(1)% :零或者多个字符,使用%有三种情况
字段 like '%关键字%'字段包含"关键字"的记录
字段 like '关键字%'字段以"关键字"开始的记录
字段 like '%关键字'字段以"关键字"结束的记录

例子:

SELECT * FROM [user] WHERE uname LIKE '%三%'

搜索结果:“张三”,“小三”、“三脚猫”,“猫三脚” 有“三” 的记录全找出来。

SELECT * FROM [user] WHERE uname LIKE '%三' (从后开始匹配)

搜索结果:“张三”,“小三”

另外,如果需要找出uname中既有“三”又有“猫”的记录,请使用and条件

SELECT *FROM [user] WHERE uname LIKE '%三%' AND uname LIKE '%猫%'

若使用SELECT * FROM [user] WHERE uname LIKE '%三%猫%',虽然能搜索出“三脚猫”,但不能搜索出“猫三脚”。

(2)_: 单一任何字符(下划线)常用来限制表达式的字符长度语句:

例子:

SELECT * FROM [user] WHERE uname LIKE '_三_'

搜索结果:“猫三脚”这样uname为三个字符且中间一个是“三”的;

SELECT * FROM [user] WHERE uname LIKE '三__';

搜索结果:“三脚猫”这样uname为三个字符且第一个是“三”的;

(3)[]:在某一范围内的字符,表示括号内所列字符中的一个(类似正则表达式)。指定一个字符、字符串或范围,要求所匹配对象为它们中的任一个。

例子:

SELECT * FROM [user] WHERE u_name LIKE '[张李王]三'

搜索结果:“张三”、“李三”、“王三”(而不是“张李王三”);

如 [ ]内有一系列字符(01234、abcde之类的)则可略写为“0-4”、“a-e”

SELECT * FROM [user] WHERE u_name LIKE '老[1-9]'

搜索结果:“老1”、“老2”、……、“老9”;

(4)[^]: 不在某范围内的字符,用法与[ ]相反。

二、在Oracle中提供了instr(strSource,strTarget)函数,比使用'%关键字%'的模式效率高很多。

instr函数也有三种情况:

instr(字段,'关键字')>0相当于 字段like '%关键字%'

instr(字段,'关键字')=1相当于 字段like '关键字%'

instr(字段,'关键字')=0相当于 字段not like '%关键字%'

例子:

SELECT * FROM [user] WHEREinstr(uname ,'三')>0

用法参照上面的Like 即可

特殊用法:

select id, namefrom user where instr('101914, 104703', id) > 0;

它等价于

select id, namefrom user where id = 101914 or id = 104703;

在数据量比较少的时候,可以直接使用上面这两种方法,但是当数据量特别大的时候,我们就应该考虑效率的问题了。虽说在效率上Instr比like关键字方法效率要高出不少,但这也仅仅是在一定程度上而言,远不能满足我们的需要。

为什么关键字查询效率这么低呢?这是由于在利用这些关键字查询的时候,数据库系统不是通过索引来查询,而是采用顺序扫描的方式来查询。显然,真是这种技术特性,造成了Like关键字查询效率的低下。特别是在复杂查询或者大表查询中,用户可以明显感觉到速度比较慢。

怎么解决效率的难题呢?答案也正是索引。

合理的利用索引,可以大幅度的提升数据库的查询性能。

关于索引的合理应用,还在研究中。。


您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

大数据中国微信

QQ   

版权所有: Discuz! © 2001-2013 大数据.

GMT+8, 2024-11-15 20:33 , Processed in 0.059562 second(s), 25 queries .

快速回复 返回顶部 返回列表