关于mysql set字段类型的模糊查询问题

WBOY
풀어 주다: 2016-06-23 14:16:58
원래의
1002명이 탐색했습니다.

有个40万条的测试数据表
flag  set('r', 'l', 'c', 'p') 

SELECT a. * , b.typedir
FROM mzrui_archives a
LEFT JOIN mzrui_kind b ON a.kid = b.uid
WHERE a.flag LIKE '%p%'
AND a.kid
IN ( 3, 17, 18 )
ORDER BY a.uid
LIMIT 0 , 15

这个语句查询需要2.5秒的时间,把like去掉后查询相当快,不知道怎么优化,求教。

uid是主键
key kid(kid,flag) 索引


回复讨论(解决方案)

既然是set,为何要like查询?   find_in_set('p',a.flag)

既然是set,为何要like查询?   find_in_set('p',a.flag)

find_in_set 的效率也是一样,我测试了,关键是find_in_set不能('c,p',a.flag)多条件,这样我查不出记录来

索引是不是有问题


既然是set,为何要like查询?   find_in_set('p',a.flag)

find_in_set 的效率也是一样,我测试了,关键是find_in_set不能('c,p',a.flag)多条件,这样我查不出记录来

你可以

find_in_set('p',a.flag) and find_in_set('c',a.flag)
로그인 후 복사
로그인 후 복사



既然是set,为何要like查询? find_in_set('p',a.flag)

find_in_set 的效率也是一样,我测试了,关键是find_in_set不能('c,p',a.flag)多条件,这样我查不出记录来

你可以

find_in_set('p',a.flag) and find_in_set('c',a.flag)
로그인 후 복사
로그인 후 복사


是可以这样,但是效率还是一样,我现在关心的是效率问题,有没有方式可以提高效率

find_in_set会全表扫描,效率确实不高。
可以考虑更改你的表结构。
新建另一个中间表存储set的内容。每次进行连接查询,同时做好字段的索引,效率应该会稍微好一点。

如果你仅仅4个标识('r', 'l', 'c', 'p') ,不如用 1 2 4 8 作为标识位,用例如 1|2 = 3 的方式来标识flag,查询的时候可以 where flag & 2 的方式,应该会快不少

如果你仅仅4个标识('r', 'l', 'c', 'p') ,不如用 1 2 4 8 作为标识位,用例如 1|2 = 3 的方式来标识flag,查询的时候可以 where flag & 2 的方式,应该会快不少

你这样的不能模糊查询啊,比如我一条记录里有 1,2,4 这样的那值应该保存的是7
我要查询包含2的记录,where flag & 2 就查询不了吧????

如果你仅仅4个标识('r', 'l', 'c', 'p') ,不如用 1 2 4 8 作为标识位,用例如 1|2 = 3 的方式来标识flag,查询的时候可以 where flag & 2 的方式,应该会快不少

我测试了下 where flag & 2 效果和 like '%l%' 效果差不多,效率并无提高啊

对于 set 类型字段 find_in_set 用的就是位运算
不过 like '%l%' 这样肯定是不可取的,如果是 like '%l,r%' 或 like '%l,p%' 不就什么都找不到了吗?
当然,无论是 like 还是 find_in_set 都是要遍历整个表的,不然就不知道哪条记录能匹配的上
set 类型是按长整形存储的,加上索引可能会快些

对于 set 类型字段 find_in_set 用的就是位运算
不过 like '%l%' 这样肯定是不可取的,如果是 like '%l,r%' 或 like '%l,p%' 不就什么都找不到了吗?
当然,无论是 like 还是 find_in_set 都是要遍历整个表的,不然就不知道哪条记录能匹配的上
set 类型是按长整形存储的,加上索引可能会快些

是啊,你说的对。我加了这个key kid(kid,flag) 复合索引,不知道这样索引对不对,目前是2.5秒左右的查询时间,我要优化到0.0几秒以内。没别的办法的话只能修改表结构了


对于 set 类型字段 find_in_set 用的就是位运算
不过 like '%l%' 这样肯定是不可取的,如果是 like '%l,r%' 或 like '%l,p%' 不就什么都找不到了吗?
当然,无论是 like 还是 find_in_set 都是要遍历整个表的,不然就不知道哪条记录能匹配的上
set 类型是按长整形存储的,加上索引可能会快些

是啊,你说的对。我加了这个key kid(kid,flag) 复合索引,不知道这样索引对不对,目前是2.5秒左右的查询时间,我要优化到0.0几秒以内。没别的办法的话只能修改表结构了

like "%xxx"这种形式的查询。.由于索引基本都是B树或者B+树,所以是不会使用索引的

like和find_in_set在查询上都会遍历整个表,对四十来万的数据也许是2.5秒,但是以后如果数据再多的话上百万的话,还会更慢,并且,这两个都不会使用索引的,所以,如果想要再提升效率的话,只能再根据业务需求,去看看能不能改善sql。

你还可以 EXPLAIN 看看 mysql 的建议

id  select_type  table  type  possible_keys  key    key_len  ref       rows    Extra  
1    SIMPLE       a    index      kid      PRIMARY    4      NULL       15   Using where 
1    SIMPLE       b    eq_ref   PRIMARY    PRIMARY    3   mzrui.a.kid    1  


用explain解析出来是这样的,有什么优化建议?

원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿