现在有4个数据表,一个是配置表 A ,一个是个性配置表 B,一个是 配置记录表 C,一个是用户表D其中,B 的数据结构 是A表的一个子集,用户的原始配置放置于A中,其他用户调用这个配置的话,共有部分的属性还是在A表中,个性配置部分是在B表中,最后由 A.B两个表一起来组合出 一个完整的配置。
现在要求从配置记录表C中去读userID为某值的 所有配置信息配置表 A :
ID x y m n ownerID
个性配置表 B:
ID AID m n userID
配置记录表 C:
ID,AID,userID
现在要求是,在配置记录表C中取出某userID的所有记录;如果在B表中也有AID的个性的配置,则用A表的 x,y 和B表的m,n 来一起组合成一个完整的配置表;如果在B表中不存在此AID,则直接从A表中取得 x,y,m,n。
相当于是 select AID from C where userID =xxx 取出来的AID 有些是单独属于A的,就是没得个性配置的,有些是A,B都有的,就是有个性配置的,现在要全部取出来在组合成一个新的集合我是这样考虑的,先从A表中取出所有userID的记录,但是排除在B中存在的
select * from A where ownerID = 1 and not exists (select 1 from B where B.AID = A.ID and n.userID = 1)
然后在取出个性配置中此userID的记录和A 表组合成一个完整的记录
select A.x,A.y,B.m,B.n from B,A where B.AID=A.ID and B.userID =1
然后把这2个集合 union all
最后在 和 配置记录表中的取出来的 AID 进行 inner join但是数据量都不大每个表也就万条记录左右,最后查询一次居然要4,5秒钟的时间。请问这种该有什么好的方法去优化呢?
现在要求从配置记录表C中去读userID为某值的 所有配置信息配置表 A :
ID x y m n ownerID
个性配置表 B:
ID AID m n userID
配置记录表 C:
ID,AID,userID
现在要求是,在配置记录表C中取出某userID的所有记录;如果在B表中也有AID的个性的配置,则用A表的 x,y 和B表的m,n 来一起组合成一个完整的配置表;如果在B表中不存在此AID,则直接从A表中取得 x,y,m,n。
相当于是 select AID from C where userID =xxx 取出来的AID 有些是单独属于A的,就是没得个性配置的,有些是A,B都有的,就是有个性配置的,现在要全部取出来在组合成一个新的集合我是这样考虑的,先从A表中取出所有userID的记录,但是排除在B中存在的
select * from A where ownerID = 1 and not exists (select 1 from B where B.AID = A.ID and n.userID = 1)
然后在取出个性配置中此userID的记录和A 表组合成一个完整的记录
select A.x,A.y,B.m,B.n from B,A where B.AID=A.ID and B.userID =1
然后把这2个集合 union all
最后在 和 配置记录表中的取出来的 AID 进行 inner join但是数据量都不大每个表也就万条记录左右,最后查询一次居然要4,5秒钟的时间。请问这种该有什么好的方法去优化呢?
from c inner join a on c.aid = a.id
left join b on a.id = b.aid
where c.UserID = 1
a.*
from
left join b
on
a.id=b.aid
where
c.userid=1
and
b.aid is null
这个isnull效率如何呢
from c inner join a on c.aid = a.id
left join b on a.id = b.aid and b.UserID = 1
where c.UserID = 1关键,你的C、B两表的UserID有无索引,所有表的aid是否有索引。
恩,我加了这userID的,只是执行速度也没变快,还是要4秒左右
数据不多,为啥速度这样慢呢,方法思路不对?
哦,对了,我还在 select A.ID,A,X 这里加了几个函数,是取相应值的,不会是这个的问题吧,我ctrl +L 看了看,那些函数消耗基本为0,应该不是这个问题
连接字段(很多业务上就是唯一的)家聚集索引几乎是必须的,这与数据量几乎无关。
常用查询条件增加索引也是提高速度的方法。所以,如果w的数据不多的话,那4、5秒不会算长的。函数先去掉测试,比较有无函数的执行时间就知道函数的影响多少了,而不应该这方面以查询计划为准。