mysql查询优化count(*)-查询记录总条数（二）

前文提到查询记录总条数有时候会使用到where来限定查询范围。

从优化原则来说，where可能会降低效率。

但是如果where设定的合理，符合一定条件，也可以实现查询优化效果。

如果条件是索引列，那么查询效率可能会较高。

不过这是对于一般的sql查询，如果前提是“查询记录总条数”，那就不一定。这需要有清醒的认识。

如果这个索引列具有跟自增长字段一致的顺序且连续，这个对于“查询记录总条数”是很好的，在缩小数据集范围的同时，还可以利用上文给出的小技巧，利用自增长字段高效得出结果。

那么在利用这一条件时，需要注意以下几点：

1.不要对时间字段使用函数

例如：year(时间字段名）

2.正确使用时间段

尽量给出开始和结束时间，尽量避免单独使用大于或小于号

3.使用between比使用大于号+小于号要好一些

当条件不具有连续性和顺序性时，如果能大量缩减数据集范围，也会有较高效率。但是就不能使用上文的小技巧了。

select count(*) from 表名 where 条件表达式;

要清楚，这时候高效是因为数据过滤后较少而达成。

当条件不具有连续性和顺序性，且过滤后数据集依旧庞大时，效率依旧会不高。这类情况该怎么办？

此时设计一些辅助统计的表可能是比较好的选择。这些辅助表帮助我们达成提升效率的目的。

例如：这些表可以存储一些统计结果，需要的时候来辅助表读取结果，而不是去原表查询。

那么有人说了，这些表的数据，不也是通过低效查询得来的么？

是的，说的没错。不过，我们能通过一些方法避免低效sql影响生产系统。

一个常见的方法就是使用主从结构，专门使用一个从库来执行类似任务。

另外，这些计算一般是一天一次或数次，不会反复执行。

有人可能认为，这不属于优化sql了。

我个人认为，目标“查询记录总条数”效率高或者说不影响生产系统的性能。这样来看，用什么具体办法都算是优化了，毕竟你不会因为低效的sql导致生产系统收到影响。