索引与优化like查询

1. like %keyword    索引失效,使用全表扫描。但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引,不走全表扫描。

2. like keyword%    索引有效。

3. like %keyword% 索引失效,也无法使用反向索引。

====================================================================
1. 使用下面的函数来进行模糊查询,如果出现的位置〉0,表示包含该字符串。
查询效率比like要高。
如果: table.field like  ‘%AAA%’ 可以改为 locate (‘AAA’ , table.field) > 0

LOCATE(substr,str)
     
POSITION(substr IN str)
返回子串substr在字符串str第一个出现的位置,如果substr不是在str里面,返回0。

使用instr
select count(*) from table t where instr(t.column,’xx’)> 0
这种查询效果很好,速度很快。

2. 查询%xx的记录

select count(c.c_ply_no) as COUNT

  from Policy_Data_All c, Item_Data_All i

 where c.c_ply_no = i.c_ply_no

   and i.C_LCN_NO like ’%245’

在执行的时候,执行计划显示,消耗值,io值,cpu值均非常大,原因是like后面前模糊查询导致索引失效,进行全表扫描

解决方法:这种只有前模糊的sql可以改造如下写法

select count(c.c_ply_no) as COUNT

  from Policy_Data_All c, Item_Data_All i

 where c.c_ply_no = i.c_ply_no

   and reverse(i.C_LCN_NO) like reverse(‘%245’)

使用翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引,不走全扫描。有效降低消耗值,io值,cpu值这三个指标,尤其是io值的降低。

本文来源于"阿里中间件团队播客",原文发表时间" 2012-04-10"

时间: 2024-10-31 20:20:04

索引与优化like查询的相关文章

mysql性能优化-慢查询分析、优化索引和配置

目录 一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询   2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_b

SQL Server索引自动优化工具

前段接手了个优化项目,大概要求是对公司现有的1W多张表进行索引优化,完善现有的,剔除无效的索引.鉴于人手严重不足(当时算两个半人的资源),打消了逐个库手动去改的念头.当前的程序结构不允许搞革命的做法,只能搞搞改良,所以准备搞个自动化工具去处理.原型刚开发完,开会的时候以拿出来就遭到运维DBA团队强烈抵制,具体原因不详.最后无限延期.这里把思路分享下.欢迎拍砖. 整个思路是这样的,索引都是为查询和更新服务的,但是不合适的索引又会对插入和更新带来负面影响.面对表上现有的索引想识别那些是有效的不太可能

PgSQL · 应用案例 · GIN索引在任意组合查询中的应用

背景 很多人小时候都有一个武侠梦,独孤求败更是金庸武侠小说里的一位传奇人物. 纵横江湖三十馀载,杀尽仇寇奸人,败尽英雄豪杰,天下更无抗手,无可奈何,惟隐居深谷,以雕为友. 呜呼,生平求一敌手而不可得,诚寂寥难堪也. 独孤老前辈的佩剑描写非常有意思,从使用的佩剑,可以看出一个人的武功修为. 第一柄是一柄青光闪闪的无名利剑.「凌厉刚猛,无坚不摧,弱冠前以之与河朔群雄争锋.」 第二柄是紫薇软剑,「三十岁前所用,误伤义士不祥,乃弃之深谷.」 第三柄是玄铁重剑,「重剑无锋,大巧不工,四十岁之前恃之横行天下

时序数据合并场景加速分析和实现 - 复合索引,窗口分组查询加速,变态递归加速

时序数据合并场景加速分析和实现 - 复合索引,窗口分组查询加速,变态递归加速 作者 digoal 日期 2016-11-28 标签 PostgreSQL , 数据合并 , 时序数据 , 复合索引 , 窗口查询 背景 在很多场景中,都会有数据合并的需求. 例如记录了表的变更明细(insert,update,delete),需要合并明细,从明细中快速取到每个PK的最新值. 又比如有很多传感器,不断的在上报数据,要快速的取出每个传感器的最新状态. 对于这种需求,可以使用窗口查询,但是如何加速,如何快速

lucene索引文件大小优化小结

   随着业务快速发展,基于lucene的索引文件zip压缩后也接近了GB量级,而保持索引文件大小为一个可以接受的范围非常有必要,不仅可以提高索引传输.读取速度,还能提高索引cache效率(lucene打开索引文件的时候往往会进行缓存,比如MMapDirectory通过内存映射方式进行缓存).       如何降低我们的索引文件大小呢?本文进行了一些尝试,下文将一一介绍. 1 数值数据类型索引优化 1.1 数值类型索引问题         lucene本质上是一个全文检索引擎而非传统的数据库系统

理解MySQL——索引与优化

写在前面:索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点.考虑如下情况,假设数据库中一个表有10^6条记录,DBMS的页面大小为4K,并存储100条记录.如果没有索引,查询将对整个表进行扫描,最坏的情况下,如果所有数据页都不在内存,需要读取10^4个页面,如果这10^4个页面在磁盘上随机分布,需要进行10^4次I/O,假设磁盘每次I/O时间为10ms(忽略数据传输时间),则总共需要100s(但实际上要好很多很多).如果对之建立B-Tree索引,则只需要进行log100(

《高并发Oracle数据库系统的架构与设计》一2.3 索引设计优化

2.3 索引设计优化 现在,我们知道了B树索引的结构特点,也了解到其对查询和排序优化的意义,但是这并不代表我们就能建好用好索引了.在实际工作中,是不是还是会遇到走了索引反而查询变慢的情况呢?虽然说不是所有的情况下索引扫描都是优于全表扫描的,但是对于一套设计成熟的系统来说,索引扫描往往是值得坚持的,应该定期进行全库SQL语句执行计划的审查,抓出全表扫描的SQL进行优化. 说一千道一万,我们创建索引就是为了使用索引,尽可能地使查询操作能够走索引.但是,很遗憾,不是我们说走索引就能走索引,还是需要取决

mysql索引提高优化order by语句用法介绍

先我们要注意一下 1>mysql一次查询只能使用一个索引.如果要对多个字段使用索引,建立复合索引. 2>在ORDER BY操作中,MySQL只有在排序条件不是一个查询条件表达式的情况下才使用索引. 关于索引一些说法 MySQL索引通常是被用于提高WHERE条件的数据行匹配或者执行联结操作时匹配其它表的数据行的搜索速度. MySQL也能利用索引来快速地执行ORDER BY和GROUP BY语句的排序和分组操作. 通过索引优化来实现MySQL的ORDER BY语句优化: 1.ORDER BY的索引

mysql中数据库索引与优化

一.索引的概念索引就是加快检索表中数据的方法.数据库的索引类似于书籍的索引.在书籍中,索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息.在数据库中,索引也允许数据库程序迅速地找到表中的数据,而不必扫描整个数据库. 二.索引的特点 1.索引可以加快数据库的检索速度 2.索引降低了数据库插入.修改.删除等维护任务的速度 3.索引创建在表上,不能创建在视图上 4.索引既可以直接创建,也可以间接创建 5.可以在优化隐藏中,使用索引 6.使用查询处理器执行SQL语句,在一个表上,一次只能使用一个索引