MYSQL的FOUND_ROWS()函数
UPDATE:FOUND_ROWS()函数貌似还存在一些问题，见http://bugs.mysql.com/bug.php?id=18454
mysql 4.1中新增了FOUND_ROWS()函数，这个函数的说明是这样的：
For a SELECT with a LIMIT clause, the number of rows that would be returned were there no LIMIT clause
A SELECT statement may include a LIMIT clause to restrict the number of rows the server returns to the client. In some cases, it is desirable to know how many rows the statement would have returned without the LIMIT, but without running the statement again. To obtain this row count, include a SQL_CALC_FOUND_ROWS option in the SELECT statement, and then invoke FOUND_ROWS() afterward:
比如说有段sql需要取出一张表的前10行，同时又需要取出符合条件的总数。这在某些翻页操作中很常见
-
SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
-
WHERE id> 100 LIMIT 10;
在上一查询之后，你只需要用FOUND_ROWS()就能获得查询总数，这个数目是抛掉了LIMIT之后的结果数:
-
SELECT FOUND_ROWS();
其中第一个sql里面的SQL_CALC_FOUND_ROWS不可省略，它表示需要取得结果数，也是后面使用FOUND_ROWS()函数的铺垫。
作者: Volcano 发表于July 3, 2007 at 7:45 am
神仙 于 2007-07-03 @ 09:40:29 留言 ：
以前在easy的blog上看到过。
似乎这个东西比另外count(*)一次要慢。
etng 于 2007-07-03 @ 09:50:41 留言 ：
基本没有用的，我如果都有返回全部的sql就不需要这个。我只选一页又用它又不准确，鸡肋。
legend 于 2007-07-03 @ 10:34:40 留言 ：
记录少还好，挺方便。记录一多，这个就比count慢多了。
qinyf 于 2007-07-03 @ 11:09:28 留言 ：
不知和count(*)比性能如何
volcano 于 2007-07-03 @ 11:30:17 留言 ：
回头做个性能测试
david 于 2007-07-04 @ 19:05:49 留言 ：
我记得当初测试结果确实比另外select count(*)还慢。
还有用mysql的存储过程也是，还不如用多条语句的快
volcano 于 2007-07-04 @ 19:33:13 留言 ：
对，在最上面的更新里有mysql的bug连接，4.1, 5.0, 5.1版本都有这个问题。mysql对FOUND_ROWS()函数优化不够,比如下面两个SQL：
select sql_calc_found_rows last_name from contacts group by c_id order by last_namelimit 1;
有sql_calc_found_rows(19.38 秒)
select last_name from contacts group by c_id order by last_name limit 1;没有 sql_calc_found_rows(3.13 秒)
差别高达8秒，可见mysql这方面的问题还是很大的，在这个bug没有修复之前，这些功能不值得使用。
bill 于 2008-02-29 @ 22:34:03 留言 ：
谢谢分享。