有个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) 索引
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) 索引
find_in_set 的效率也是一样,我测试了,关键是find_in_set不能('c,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 的效率也是一样,我测试了,关键是find_in_set不能('c,p',a.flag)多条件,这样我查不出记录来你可以
find_in_set('p',a.flag) and find_in_set('c',a.flag)是可以这样,但是效率还是一样,我现在关心的是效率问题,有没有方式可以提高效率
可以考虑更改你的表结构。
新建另一个中间表存储set的内容。每次进行连接查询,同时做好字段的索引,效率应该会稍微好一点。
你这样的不能模糊查询啊,比如我一条记录里有 1,2,4 这样的那值应该保存的是7
我要查询包含2的记录,where flag & 2 就查询不了吧????
我测试了下 where flag & 2 效果和 like '%l%' 效果差不多,效率并无提高啊
不过 like '%l%' 这样肯定是不可取的,如果是 like '%l,r%' 或 like '%l,p%' 不就什么都找不到了吗?
当然,无论是 like 还是 find_in_set 都是要遍历整个表的,不然就不知道哪条记录能匹配的上
set 类型是按长整形存储的,加上索引可能会快些
是啊,你说的对。我加了这个key kid(kid,flag) 复合索引,不知道这样索引对不对,目前是2.5秒左右的查询时间,我要优化到0.0几秒以内。没别的办法的话只能修改表结构了
是啊,你说的对。我加了这个key kid(kid,flag) 复合索引,不知道这样索引对不对,目前是2.5秒左右的查询时间,我要优化到0.0几秒以内。没别的办法的话只能修改表结构了like "%xxx"这种形式的查询。.由于索引基本都是B树或者B+树,所以是不会使用索引的
1 SIMPLE a index kid PRIMARY 4 NULL 15 Using where
1 SIMPLE b eq_ref PRIMARY PRIMARY 3 mzrui.a.kid 1
用explain解析出来是这样的,有什么优化建议?