1. 一个表中有120个字段,col1,col2.....col120,但是每个字段都是bit类型,尤其当这个表条件查询的时候, 100
1.一个表中有120个字段,col1,col2.....col120,但是每个字段都是bit类型,尤其当这个表条件查询的时候,大致有20个用and连接的条件。如selec...
1.
一个表中有120个字段,col1,col2.....col120,但是每个字段都是bit类型,尤其当这个表条件查询的时候,大致有20个用 and 连接的条件。
如 select * from table where col1=1 and col2=1 and col3=1 ......and col20=1
请问这样子查询速度快吗?这个表这样的结构,随着记录的增大会不会使数据库数据量过快的变大?
2.如果我采用这种表结构呢
不要那么多字段,只要一个varchar类型字段,条件筛选时我这样子做
select * from table where charindex(col,'某字符串1')>0 and charindex(col,'某字符串2')>0 and ......charindex(col,'某字符串20')>0 展开
一个表中有120个字段,col1,col2.....col120,但是每个字段都是bit类型,尤其当这个表条件查询的时候,大致有20个用 and 连接的条件。
如 select * from table where col1=1 and col2=1 and col3=1 ......and col20=1
请问这样子查询速度快吗?这个表这样的结构,随着记录的增大会不会使数据库数据量过快的变大?
2.如果我采用这种表结构呢
不要那么多字段,只要一个varchar类型字段,条件筛选时我这样子做
select * from table where charindex(col,'某字符串1')>0 and charindex(col,'某字符串2')>0 and ......charindex(col,'某字符串20')>0 展开
2个回答
展开全部
1. 使用字符串的方式还不如使用bit 字段类型, 因为在使用时还要用charindex处理
2. 可以推荐你使用几个Int类型来保存, 使用 "&", 也就是逻辑与 运算符来进行判断
举例说明: 这里把Int换成二进制, 例如11111000, 可以使用第一位来表示 bit1, 第二位来表示bit2....
使用时这样做 where col1 & 255 = 255 (255也就是 11111111, 如果这个条件不满足, 则说明中间肯定有一个值是0)
3. 如果不是必须, 不要使用有这么多字段的表, 尽量把它们分开
2. 可以推荐你使用几个Int类型来保存, 使用 "&", 也就是逻辑与 运算符来进行判断
举例说明: 这里把Int换成二进制, 例如11111000, 可以使用第一位来表示 bit1, 第二位来表示bit2....
使用时这样做 where col1 & 255 = 255 (255也就是 11111111, 如果这个条件不满足, 则说明中间肯定有一个值是0)
3. 如果不是必须, 不要使用有这么多字段的表, 尽量把它们分开
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
20个and连接的条件效率如何,取决于你这20个and条件上是否有索引。
你需要建一个20个字段的复合索引,从而保证查询效率。
数据量增长确实会比单一字段能大一些,但是以目前的存储价格,也算不上什么。
如果你用一个字段,然后做20个函数运算来判断是否满足条件,就要建20个函数的复合函数索引,否则无法利用原有的其他索引。如果你的数据库不支持函数索引,那么数据量一大,没有索引的查询效率可能干脆就是不可用。
所以我的建议是:老老实实存20个字段,并建一个20字段的索引。首先保证效率,空间浪费个几块钱不算个啥。
你需要建一个20个字段的复合索引,从而保证查询效率。
数据量增长确实会比单一字段能大一些,但是以目前的存储价格,也算不上什么。
如果你用一个字段,然后做20个函数运算来判断是否满足条件,就要建20个函数的复合函数索引,否则无法利用原有的其他索引。如果你的数据库不支持函数索引,那么数据量一大,没有索引的查询效率可能干脆就是不可用。
所以我的建议是:老老实实存20个字段,并建一个20字段的索引。首先保证效率,空间浪费个几块钱不算个啥。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询