SQL_CALC_FOUND_ROWS速度讨论



关于大牛们对于MySQL的查询总数之间的讨论至今争执不休， 于是我就做了如下操作证明了一下大牛们的结论

关于对于SQL_CALC_FOUND_ROWS和count再次查询一遍用法的结论：
数据量在10000条左右是差不多的效率；

当数据多于10000条的时候SQL_CALC_FOUND_ROWS数据会明显下降。

而当小于10000的时候SQL_CALC_FOUND_ROWS的优势会呈现出来但是也不是很明显， 所以， 综上所述， 还是count求和把， 不用解释了。

下面是我的测试代码， 没有办法截图给你们看我的效率了， 你们自己也可以试试

SELECT sys_date  FROM  ds_tr WHERE sys_date  LIKE '%2017%' LIMIT 1, 100;          -- LIMIT 1, 100;
SELECT COUNT(*)  FROM  ds_tr WHERE sys_date  LIKE '%2017%'
SELECT FOUND_ROWS();

下面是我的一些测试代码和数据

-- SQL_CALC_FOUND_ROWS在速度上会比COUNT(*)慢很多,具体有多慢,取决于你的索引还有一些别的因素, count大约要比SQL_CALC_FOUND_ROWS快上10倍.

--  似乎不可以，总数只能count出来，如果是用jdbc的话，有个偷懒的方法,似乎使用 scrollable resultset。

-- 1. 生产环境,绝对不要使用 SQL_CALC_FOUND_ROWS , 效率往往比不上你单独执行2条sql,  因为实质是把这条sql全部执行一遍,获取所有结果集,然后抛弃大部分不需要的数据; 你可以单独select count (id ) ;2. 一般不需要获取总数,如果你是开发一个高性能的程序 ,这是一个开发大忌.  这种耗资源的操作不需要准确,也不需要频繁执行.