受け入れられた答えは間違っているようです。LIMIT を含むクエリの後に found_rows() を使用することをお勧めします。
ANSWER : 問題は RETURN 1 と、場合によっては found_rows(); の結果としての 0 についてです。
最初の選択ステートメントの後に他のクエリが実行されたときに発生します。特に IDE や一部のクライアントを使用してクエリを実行している場合は、クエリの前後に追加の「準備」クエリが実行されます。
また、found_rows() は、サーバーで実行された最後のクエリによって返された結果の数を返します。この場合、これは私たちが期待するものではありません。
したがって、RETURN 1 または 0 エラーです。
検証:
サーバーで一般的なログ記録を有効にし、クエリを実行することで、これを検証できます。「最初のクエリと見つかった行のクエリ」の間に実行される追加のクエリがいくつか表示されます。
FIX
ストアド プロシージャ、または古い COUNT(*)。
パフォーマンスに関しては、ほとんど違いはありません。
追加
オブジェクトが返された行の総数を見つけることである場合は、問題ありません。SQL_CALC_FOUND_ROWS の使用は重要ではなくなります。
これが一般的なルールです。見つかった行や SQL_CALC_FOUND_ROWS には LIMIT は必要ありません。しかし、それらのうちの 3 つを一緒に使用して、非常に有用な結果を得ることができます。
つまり、次のようなものを実行しています。
SELECT SQL_CALC_FOUND_ROWS * from some_table_name LIMIT 0,10;
SELECT FOUND_ROWS();
SELECT * from sometable_name; を実行した場合にクエリによって返される行数を取得します。すなわち: LIMIT なし。
そうは言っても、
SELECT * from some_table_name LIMIT 0, 10;
SELECT FOUND_ROWS();
制限のcosが<= 10になる結果の総数が得られます。実用的な目的はありませんが、エラーではありません。