【参考】mysql like %keyword%不走索引替代方法


  在使用msyql进行模糊查询的时候,很自然的会用到like语句,通常情况下,在数据量小的时候,不容易看出查询的效率,但在数据量达到百万级,千万级的时候,查询的效率就很容易显现出来。这个时候查询的效率就显得很重要!

一般情况下like模糊查询的写法为(field已建立索引):

SELECT `column` FROM `table` WHERE `field` like '%keyword%';

上面的语句用explain解释来看,SQL语句并未用到索引,而且是全表搜索,如果在数据量超大的时候,可想而知最后的效率会是这样

对比下面的写法:

SELECT `column` FROM `table` WHERE `field` like 'keyword%';

这样的写法用explain解释看到,SQL语句使用了索引,搜索的效率大大的提高了!

但是有的时候,我们在做模糊查询的时候,并非要想查询的关键词都在开头,所以如果不是特别的要求,"keywork%"并不合适所有的模糊查询

这个时候,我们可以考虑用其他的方法
1.LOCATE('substr',str,pos)方法

SELECT LOCATE('xbar',`foobar`); 
    ###返回0

SELECT LOCATE('bar',`foobarbar`); 
    ###返回4

SELECT LOCATE('bar',`foobarbar`,5);
    ###返回7
备注:返回 substr 在 str 中第一次出现的位置,如果 substr 在 str 中不存在,返回值为 0 。如果pos存在,返回 substr 在 str 第pos个位置后第一次出现的位置,如果 substr 在 str 中不存在,返回值为0。

SELECT `column` FROM `table` WHERE LOCATE('keyword', `field`)>0

备注:keyword是要搜索的内容,field为被匹配的字段,查询出所有存在keyword的数据

2.POSITION('substr' IN `field`)方法
    position可以看做是locate的别名,功能跟locate一样

SELECT `column` FROM `table` WHERE POSITION('keyword' IN `filed`)

3.INSTR(`str`,'substr')方法

SELECT `column` FROM `table` WHERE INSTR(`field`, 'keyword' )>0

 

除了上述的方法外,还有一个函数FIND_IN_SET

FIND_IN_SET(str1,str2):
返回str2中str1所在的位置索引,其中str2必须以","分割开。

SELECT * FROM `person` WHERE FIND_IN_SET('apply',`name`);

以上方法在使用 * 时不走索引, 使用多个列时走所以.

mysql5.6中已经解决了
like %keyword% 第一个%分好的问题.但注意EXPLAIN SELECT city_id ,city FROM city
WHERE city LIKE '%xin%';   select 的列不能时* 否则不走索引.

mysql like 查不到结果 中文 查询优化的更多相关文章

  1. MYSQL一次千万级连表查询优化(一)

    摘自网上学习之用 https://blog.csdn.net/Tim_phper/article/details/78344444 概述: 交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的 ...

  2. [转]关于Navicat和MYSQL字符集不统一出现的中文乱码问题

    原文链接:关于Navicat和MYSQL字符集不统一出现的中文乱码问题 最近遇到一串关于MYSQL中文乱码的问题,问题背景是这样的: 在此之前,服务器上安装好MySQL之后就立马重新配置了字符集为ut ...

  3. ( 转 ) 优化 Group By -- MYSQL一次千万级连表查询优化

    概述: 交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的功能,这算是离职人员挖下的坑,随着数据越来越多,原本的SQL查询变得越来越慢,用户体验特别差,因此SQL优化任务交到了我手上. 这个 ...

  4. MySQL 存储php中json_encode格式中文问题及解决

    MySQL 存储php中json_encode格式信息  ,遇到中文时, 会变成一堆类似uxxxx信息. 1. 原因分析:在存储到数据库时!MySQL 不会存储 unicode 字符: MySQL 仅 ...

  5. Ubuntu 15.04下MySQL 5.6.25不支持中文解决办法

    Ubuntu 15.04下MySQL 5.6.25不支持中文解决办法,apt-get install 安装的,不是源码包安装的mysql. 1 修改mysql的配置文件 /etc/mysql/conf ...

  6. Mybatis使用MySQL进行模糊查询时输入中文检索不到结果

    Mybatis使用MySQL进行模糊查询时输入中文检索时,需要在jdbcURL后增加参数   ?useUnicode=true&characterEncoding=UTF-8

  7. mysql操作命令梳理(4)-中文乱码问题

    在平时的mysql运维操作中,经常会碰到插入中文字段后出现乱码的情况,产生中文乱码的原因一般有:1)mysql的编码格式不对,是latin1编码.强烈推荐将mysql下的编码格式都改为utf8,因为它 ...

  8. MYSQL一次千万级连表查询优化

    概述:交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的功能,这算是离职人员挖下的坑,随着数据越来越多,原本的SQL查询变得越来越慢,用户体验特别差,因此SQL优化任务交到了我手上. 这个S ...

  9. MYSQL一次千万级连表查询优化(二) 作为一的讲解思路

    这里摘自网上,仅供自己学习之用,再次鸣谢 概述: 交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的功能,这算是离职人员挖下的坑,随着数据越来越多,原本的SQL查询变得越来越慢,用户体验特别 ...

随机推荐

  1. It is not safe to rely on the system's timezone settings错误

    在写php程序中有时会出现这样的警告: PHP Warning: date(): It is not safe to rely on the system's timezone settings. Y ...

  2. Python 列表(List)-文摘

    原文地址:http://www.runoob.com/python/python-lists.html Python 列表(List) 序列是Python中最基本的数据结构.序列中的每个元素都分配一个 ...

  3. 产品开发- DFX

    一.DFE(Design for Environment)面向环境的设计 二.DFM(Design for Manufacture)面向制造的设计 DFM的最终设计的主要目的是对产品成本的控制,主要包 ...

  4. Ruby面向对象

    Ruby面向对象 ​ Ruby是真正的面向对象语言,一切皆为对象,甚至基本数据类型都是对象 基本用法 class Box # 构造函数 def initialize(w,h) @with, @heig ...

  5. 部署前准备--使用Mysql之Django Debug Toolbar安装以及配置

    python -c "import django ;print(django.__path__);" 查看python的全局配置 vi /usr/local/lib/python3 ...

  6. Java中Double类型的精确计算

    import java.math.BigDecimal; public class DoubleUtil { private static final int DEF_DIV_SCALE = 5; / ...

  7. JDBC(12)—DBUtils工具类

    DBUtils:commons-dbutils是Apache组织提供的一个开源JDBC工具库,它是对JDBC的简单封装,并且使用dbutils会极大的简化jdbc编码的工作量,同时不会影响到程序的性能 ...

  8. GoogLeNet 解读

    GoogLeNet系列解读 2016年02月25日 15:56:29 shuzfan 阅读数:75639更多 个人分类: 深度学习基础    版权声明:本文为博主原创文章,转载请注明出处 https: ...

  9. Centos yum国内源及配置含义

    Centos yum源的位置: /etc/yum.repos.d,可以通过配置文件/etc/yum.conf指定其他位置 主要的yum源种类:前两个是必须的,不然yum安装很多软件时会失败.yum本来 ...

  10. golang time打印出的值是62135596800的来源

    ' 减去62135596800是将"以公元1年1月1日0点为基准"改成"以1970年1月1日0点"为基准 所以,数据库datetime的默认值 : 0000-0 ...