有一张UserMsg，用户短信表，里面msgid,Title,Msg,toUser,fromUser,isRead字段，
toUser,fromUser有建立索引
获取某用的短信时，我用select count(0) from UserMsg where toUser=@toUser
数据还可以，但要获取某用户的未读短信的时候，我用 select count(0) from UserMsg where toUser=@toUser and isRead=0
速度就慢多了。isRead，没有建立索引。这个字段 不是0，就是1，建立索引网上看，这样的值不适合建立索引。同样，感觉维护成本也比较大。
UserMsg表数据在千万级别，大家认为有要怎么来出来比较好。
------解决方案--------------------
要看你这个数据是怎么进去的，如果是慢慢积累着进去的，可以做一张表，两个字段（touser，msgcount），每次新增或者删除的时候操作这个表，这样查询就快多了。
如果数据更新量很快，那显然上面这个方法就不适合了，也可以考虑将touser和isread两个建联合索引。其实按道理即使isread没有建立索引，touser建立了索引了，应该查询也不会太慢啊。因为满足touser条件的应该不会太多了吧，如果满足touser的1000条的话，需要匹配isread的就只需要匹配1000次就可以了，应该还是比较快的。
------解决方案--------------------
不适合建立索引应该是针对数据量小的情况下吧,再说优化操作是针对于查询的,也就是针对是实际应用的.
对于大数据量来说,没有什么简单的规则可以直接死搬硬套的.
------解决方案--------------------
你只说了快慢，没说快的时候要多久？慢的时候要多久？
count()括号里面指定主键，不要count(*)。如果速度还是跟不上，那就需要从以下几个方面着手。
第一个，升级硬件，千万级的数据，如果你的硬件不好，那就不光是这一个查询慢的问题了。
第二，如果硬件确实穷的搞不起（呵呵，咱都是穷人），那就拆分表，库，让每个表的数据不超过100万。
第三，拆分表库要改程序？麻烦？那就启动一个独立的进程，把这样的统计每隔一段时间（1小时？一天？，看你们统计的频率了）执行一次，然后写到一个表中，然后你查询的时候就去查那个表吧。（注意，不是在数据插入，更新的时候同步搞这种事情）。