优化sqllike
⑴ sql语句查询，多字段like模糊查询优化
1、多字段like模糊查询优化：
最常见的写法：
where a like '%xx%' or b like '%xx%' or c like '%xx%';
这种写法查询效率低，经过调查，下面的方法可以替代，并且效率高：
2、如果like的关键字相同：
where instr(nvl(a, '')||nvl(b,'')||nvl(c,''), 'xx') > 0
把要模糊查询的字段先拼接起来，拼接时需要把null转成‘’，否则只要有一个字段值是空，整个拼接的字符串都成空了， 然后用instr 函数去过滤；
3、如果like的关键字不同：
where instr(a, 'xx') > 0 or instr(b, 'yy') > 0 or instr(c, 'zz') > 0
经过测试，这两种方法都比like效率要高；
⑵ sybase数据库的“like”用法是什么
想在SQL LIKE里查询有下划线'_'或是'%'等值的记录，直接写成like 'XXX_XX'，则会把'_'当成是like的通配符。
SQL里提供了 escape子句来处理这种情况，escape可以指定like中使用的转义符是什么，而在转义符后的字符将被当成原始字符，这和C里的''很像，但是escape要求自定义一个转义符，而不是指定了'’字符。
⑶ 一条sql:如何优化 where name like '%ab%' or name like
方法一: 将or条件变为3个查询，然后用union将3个查询的结果集合并起来(or会降低查询效率)。
方法二: 使用类似正则表达式的匹配将3个like合并, name like '%[ab|cd|ef]%'。注意，这个需要数据库支持。
⑷ Sql优化-多like模糊查询及根据时间排序
2020-04-21
记录一次sql优化记录：
环境：用的mysql版本 select Version();
优化过程：
用的是两张表联查，四个条件like查询 ，根据时间排序降序
其中A，B表没有大字段，A表20万多数据，B表50万多条数据。语句如下：
EXPLAIN
SELECT A.bondId,A.sname,A.cname,A.secuCode,A. ISSUER,A.guarantor,B.underwriter AS infoSource
FROM A
LEFT JOIN B ON B.bondId = A.bondId
WHERE B.agentType = 1
AND B.underwriter = '有限公司'
AND A.startDate <= '2020-04-21 18:02:10'
AND A.endDate >= '2020-04-21 18:02:10'
AND (
A.cname LIKE '%%' OR A.sname LIKE '%%' OR A.secuCode LIKE '%%'
OR A. ISSUER LIKE '%%'OR A.guarantor LIKE '%%')
AND A.isValid = 1
ORDER BY A.startDate DESC
LIMIT 0, 20
这是2个表都没有加索引的情况，从explain来看结果非常糟糕，都是全表扫描，并且产生临时表同时有文件排序，效率肯定非常低。
首先尝试在B表上建立一个联合索引
可以考虑从关联字段及where条件字段考虑（bondId, underwriter, agentType）
建一个联合索引，试试。
ALTER TABLE B ADD INDEX bua_index(bondId, underwriter, agentType)
再explain看：
可以看到B表用到了我们刚刚建的联合索引，并且额外信息是Using index ，type是ref级别的，效果比较理想，再来看A表。
Where条件中有多个like，这种情况下一般索引都是不可用的，所以必须用覆盖索引解决，
由于又根据startDate排序，所以尝试根据如下字段建立联合索引，同时查询的字段就是索引中的字段（startDate, endDate,cname, sname, secuCode, issuer, guarantor）
ALTER TABLE A ADD INDEX index_scssig(startDate, endDate,cname, sname, secuCode, issuer, guarantor)
再次explain看看效果：
这样乍看上去A表也用到了刚刚建的联合索引，并且type是range级别虽然比ref差点，按理说应该也还可以，但是我执行sql语句，效率还是非常差，查询耗时达到8s，并且偶尔还不止这个时间
究其原因，虽然使用了索引，但是extra里面是Using index condition&Using where
回表操作了，我在想如果将extra优化成Using index效率肯定没问题
故再进一步优化，还是从索引入手
在联合索引上添加2个字段isValid, bondId 再试试
ALTER TABLE A ADD INDEX index_scssig(isvalid,startDate, endDate,cname, sname, secuCode, issuer, guarantor,bondId)
再次explain:
这个结果就是我想要的，然后执行sql看看效率：
已经提升了很多了，但是我试了别的查询条件偶尔时间会到3，4s,怀疑和自己的机器有关
在这这种多个like的or查询mysql本身并不擅长，无奈坑爹的需要需要这样，可能效率并不是非常的高，优化成这样可以接受了。
最近对以前项目的慢查询进行sql调优，感觉性能的下降往往还是sql语句及索引的建立的问题，explain是很有帮助，正确优化还是能极大提升效率的。