关于sql语句优化like的问题

like 是模糊查询,通配符%表示任意字符，like ‘%5400%’ 这个条件要进行全表扫描，而 YY_BH LIKE ’X5400%’ 表示只查询前面字符为：'X5400‘的所有字符，这时是使用索引查询的，所以速度快。

傻逼啊，谁看了这个文章就是误人子弟 方案1：主键Id，默认为聚集索引，不建立其它非聚集索引select from News where Title like '%"&abigale&"%' or Author like '%"&abigale&"%' order by Id desc从字段Title和Author中模糊检索，按Id排序查询时间：50秒方案2：主键Id，默认为聚集索引在Title、Author、Star上建立非聚集索引select from News where Title like '"&abigale&"%' or Author like '"&abigale&"%' order by Id desc从字段Title和Author中模糊检索，按Id排序查询时间：2 - 25秒 看到没有，那个50秒用的是 '%"&abigale&"%'来的，两个百分号会引发全表扫描而那个快的是 '"&abigale&"%' ，这样就使用索引 不用索引和用索引完全两个概念，尼玛还在说优化，优化你妹

从explain开始说起吧，很显然第一个sql语句压根没用任何索引（key列内什么都没有）！第二个倒是用到索引，却是主键索引，并非你添加的fulltext索引！

接下来，分析下原因：

sql1：执行步骤：先s_a和s_a_t两表笛卡尔集，然后筛选满足on条件的，接着在从结果集中筛选满足where字句的；该过程中处理的记录条目为69105479，并且未用到任何索引，未用到的原因可能是你先定义了一个复合索引a_concent_split（a_title_split，a_content_split），然后又定义了一个a_content_split2（a_content_split），当引擎执行查找优化时候会先用到a_content_split，可是又由于复合索引是从最左边开始（不能跳过第一个字段），而你却忽略了a_title_split字段，故未能正常使用索引。

sql2：执行步骤：先调用where字句对s_a表进行筛选形成新的s_a表，然后与s_a_t表笛卡尔积，再利用on字句筛选，最后再次利用where字句形成最终结果集；经过第一个where，该过程处理结果集会大幅少于sql1，并且该过程还用到了主键索引。你所设置的fulltext索引再次没有用到，原因是like字句中开始部分为模糊匹配%时候用不了全文索引，这与fulltext存储机制有关。

另，你说的删除速度慢，原因：设置fulltext字段设置太多，fulltext索引在更新删除大量数据时候，需要同步更改索引，你的三个fulltext压力太大！

改进方法：1、删除a_content_split索引重试 2、在删除时候打开delay_key_write变量

有关fulltext比较复杂，用的时候要谨慎设置，还有很多参数也对其有影响

另外sql语句中外连接有关on where字句也是个比较绕的地方，两者你都占了，唉，所以我写的略复杂，前天看到该问题，思忖两天这才作答

望有结果了予以回复交流！

你这条语句的意思相当于查找test表中所有province为四川，并且city为成都，并且某个字段包含cpu的数据信息。注意：like前边是要有字段名的，你这样的写法是会报语法错误的。影响不影响的问题呢，就看你的查询目的是什么了，如果是查询四川并且成都，而又或者某字段包含cpu的数据，建议这样写：select form test where （province = '四川' AND city = '成都'） or 某字段 like '%CPU%';

like 要是使用索引 就必须这样写 like ‘a%’ 或者 ‘%a’，两边都加上是不会触发索引的。想想你也知道，没有一个确切的值怎么能按一定条件查找数据呢？‘%a%’这种写法只会造成全表扫描。

以上就是关于关于sql语句优化like的问题全部的内容，包括:关于sql语句优化like的问题、如何优化Sql server 大数据量时使用 like 查询的速度或有什么别的方法实现模糊查询、mysql全文索引 很慢，速度不如like的百分之一等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！