这个unique约束在mssql中如何建立

首先id是主键，email是不能重复的，但是后面有个disabledflag字段，标志这列是否可用，如果disabledflag=1的情况下，那么email字段是可以重复的，如果disabledflag=0的情况下，email是不能重复的，也就是说有效的email只能有一个，这个约束如何建立。

你like 里面的东西是不是就那几个关键字呀？要是这样就好办了，你建一个作业，再建几个辅助的表，每隔一段时间把这些符合要求同步到那几个相应的表里面就好！这样根据条件再查询的话直接从那几个表里面调数据！

现在我总结一下问题：关于搜索，必须是模糊查询，如果不用 like'%%'，那用什么呢？这样一来，索引就起不到作用了，如果是 like'%'，又完全不符合查询要求。。我现在奇怪的是，，我见过很多查询系统，他们的数据都是百万级别，而且没有分页，从百万记录中查出几十条，速度很多，几秒就完成了，比如这个系统：l 它的数据很大，查询没有分页，但是速度很快，不知道这种是怎么做到的。。

是返回的速度慢你要是返回100个字段，那怕是返回一行，也慢呀
再说你的那个网站，他给你显示的是前2屏，后面的异步执行，
你没有看到一直在增加吗，不是一次出来的

你还想优化的话，不能从SQL级别来优化了，要从性能方面着手了

1 加内存,升级cpu(如果能加cpu那是最好的),把你数据库所在磁盘分区(数据库文件组)放到raid0去,硬件不上去速度何从谈起,给你老板一台486让他去优化去吧你说你能优化出来那你就不要工资了
2 写到存储过程去3 如果是2005 试试看数据分区
如果你老板懂技术,好好和他解释一下,应该能理解,如果不懂那也甭麻烦了,直接走人吧

用SQL语句或索引是没办法解决这个问题的。
数据库级的解决方案是用全文引索，比较简单，响应应该是在百毫秒级。
程序级的解决方案是针对查询字段建立Trie树的缓存，涉及缓存同步的问题，初始化以后响应可以做到毫秒以下。

如果Trie树只缓存主键的话，还是要用in语句查询数据库，这个应该是十毫秒级的。

想办法看看设计上能否改进，如表的字段长度设计是否太大，减小以缩小索引占据的硬盘空间也可以提高性能

取全部字段的话，一个一个写出来与写*效果是一样的吧
这学期才学的数据库，还不知道SQL语句也可以优化执行速度

我想最大效率的解决办法应该是全文索引吧，，可以我们个人用的操作系统一般都是XP和WIN7，听说是server版的操作系统的SQL数据库才有全文索引组件服务吧，，所以我这样就没法使用全文索引咯。。

我写了存储过程 来执行查看总计记录，，发现和直接执行SQL查询的时间一样，50W记录，都在7-8秒左右，存储过程不是可以很大效率提高速度吗？怎么没效果？？当然，存储过程里面，我也用的是like，这个有影响吗？？

我刚刚发现一个问题，我写了个模糊查询的存储过程，，我对比一下和直接执行SQL的运行时间，当查找出有记录的时候，使用了存储过程要比直接执行SQL的快一倍，，但是如果查询无结果的时候，存储过程执行的时间还是以前的，而直接SQL运行的时间只有0.5秒，，这怎么回事？？当搜索任意字符串 "dsfsdfsderw34234"，当然查询无数据
建议用sql server提供的全文索引的功能，对goodnumber建全文索引，模糊查询方法无解。

让老板来优化，能优化的出来，你就走人，优化不出来，你看他怎么说

来源：nba直播