前文提到查询记录总条数有时候会使用到where来限定查询范围。
从优化原则来说，where可能会降低效率。
但是如果where设定的合理，符合一定条件，也可以实现查询优化效果。
如果条件是索引列，那么查询效率可能会较高。
不过这是对于一般的sql查询，如果前提是“查询记录总条数”，那就不一定。这需要有清醒的认识。
如果这个索引列具有跟自增长字段一致的顺序且连续，这个对于“查询记录总条数”是很好的，在缩小数据集范围的同时，还可以利用上文给出的小技巧，利用自增长字段高效得出结果。
那么在利用这一条件时，需要注意以下几点：
1.不要对时间字段使用函数
例如：year(时间字段名）
2.正确使用时间段
尽量给出开始和结束时间，尽量避免单独使用大于或小于号
3.使用between比使用大于号+小于号要好一些
当条件不具有连续性和顺序性时，如果能大量缩减数据集范围，也会有较高效率。但是就不能使用上文的小技巧了。
select count(*) from 表名 where 条件表达式;
要清楚，这时候高效是因为数据过滤后较少而达成。
当条件不具有连续性和顺序性，且过滤后数据集依旧庞大时，效率依旧会不高。这类情况该怎么办？
此时设计一些辅助统计的表可能是比较好的选择。这些辅助表帮助我们达成提升效率的目的。
例如：这些表可以存储一些统计结果，需要的时候来辅助表读取结果，而不是去原表查询。
那么有人说了，这些表的数据，不也是通过低效查询得来的么？
是的，说的没错。不过，我们能通过一些方法避免低效sql影响生产系统。
一个常见的方法就是使用主从结构，专门使用一个从库来执行类似任务。
另外，这些计算一般是一天一次或数次，不会反复执行。
有人可能认为，这不属于优化sql了。
我个人认为，目标“查询记录总条数”效率高或者说不影响生产系统的性能。这样来看，用什么具体办法都算是优化了，毕竟你不会因为低效的sql导致生产系统收到影响。
1600
