問題タブ [sql-calc-found-rows]

アプリケーションでいくつかのクエリのパフォーマンスを最適化しようとしています。

複数の結合と全文検索を含む 1 つのクエリでSQL_CALC_FOUND_ROWS、ページネーションの最初のクエリで使用します。

残念ながら、クエリのパフォーマンスは非常に遅く、SQL_CALC_FOUND_ROWSクエリを使用しない場合は約 100 倍速くなります。

この場合、パフォーマンスが向上する可能性はありますか?

なしで単一の count-query を試しましたSQL_CALC_FOUND_ROWSが、このクエリはSQL_CALC_FOUND_ROWS-query よりもさらに 1 秒遅くなります。

私は現在SQL_CALC_FOUND_ROWS、準備されたステートメントで実装する方法について頭を悩ませています。

私はページネーションクラスを書いていますが、明らかにクエリに LIMIT を追加したいだけでなく、行の総数を調べたいと思っています。

問題のクラスの例を次に示します。

SQL_CALC_FOUND_ROWS実際の値を取得する方法について少し困惑していますか? 次のようなものを追加することを考えていました：

しかし、それは LIMIT に基づいた数を与えるだけなので、上記の例では、本来あるべき完全な 6 ではなく 3 になります。

Tomcat で実行している Web アプリケーションが次の例外をドロップすることが多いという問題があります。

したがって、次の構成でプールから接続を取得する前に、接続を検証したいと思います。

spring jdbcTemplate で次の 2 つのクエリを送信する場合:

「SELECT FOUND_ROWS()」クエリは、検証クエリが間に実行されるため (「SELECT 1」)、常に 1 を返します。

誰かが 2 番目のクエリで COUNT を使用せずにこの問題を解決する方法を知っていますか?

zf2 で SQL_CALC_FOUND_ROWS を使用して単純な選択ステートメントを使用しています。コードは次のようになり、量指定子を使用します。

そして、生成されたSQLは以下のとおりです

スクリーンショット:

しかし、何らかの理由で、found_rows は常に 0 として返され、ページネーションのために 2 つ目のクエリを追加したくありません。助けてください。

私は MySQL を使用しており、PRE_REGISTERED と REGISTERED の 2 つの別個のテーブルがあり、UNION を使用してクエリを実行し、結合結果全体を取得したいと考えています。ページネーションにも limit を使用します。最後に、ページネーションに SQL_CALC_FOUND_ROWS を使用して合計行を取得したいと思います。ただし、私のデータは PRE_REGISTERED で約 160,000 行とかなり大きいです。データを各ページに 10 行に制限しても、UNION ALL を実行すると、クエリにかなりの時間がかかります (約 6 秒)。このようなクエリ

次に、各サブクエリに LIMIT を設定しようとしましたが、結果は魅力的です (約 0.5 秒) が、ページネーションが台無しになります。

クエリは次のようになります。

サブクエリで LIMIT を使用して合計行を取得する方法はありますか?

クエリ全体を入れることにしましたが、かなり長いです。誰かがエラーを見つけて助けてくれることを願っています。私は完全に立ち往生しています。

私の実際の SQL クエリ

UNION ALL (

PS。インデックスに必要なほとんどすべての列を配置しました。

スキーマをここに表示します

それで全部です！スキーマ... ふぅ。ドリューを助けて。:)

EXPLAIN テーブル

統計結果:

以前は PHP 5.4 で実行されていた laravel 4.1 アプリケーションがありますが、5.6.13 にアップグレードしてから (そして今日は 5.6.14 に)、クエリが に対して 0 を返すことがあることに気付きましたFOUND_ROWS()。一部のクエリでは断続的であるように見えますが、他のクエリでは永続的な問題です。

最も影響を受けるセットは、サブクエリを含むセットです。

PDO を使用しています (laravel モデルは使用しておらず、PDO オブジェクトと直接やり取りしているだけです)。この期間、MySQL も変更されていません。

すべての種類を試しました - 1 つの提案は、トレース モードを 0 に設定することでしたが、それは役に立ちませんでした。false に設定しよPDO::MYSQL_ATTR_USE_BUFFERED_QUERYうとしましたが、選択しようとすると PDO エラーが発生しますFOUND_ROWS()(現在、正確なメッセージを取得できません)。

5.4 にロールバックすることはできませんが (神にお願いします)、私は完全に立ち往生しています...

これらのクエリを MySQL で直接実行してから実行すると、FOUND_ROWS() 常に正しい結果が返されます。

必要以上に実行速度が遅いクエリがあります。問題を単純な select ステートメントに絞り込みました (一部のフィールドはプライバシーのために名前が変更されています)。

を使用するSQL_CALC_FOUND_ROWSと、クエリは約 0.70 秒で完了しますが、SQL_CALC_FOUND_ROWSを削除すると、クエリは約 0.0005 秒で完了します (どちらの場合もSQL_NO_CACHEクエリで使用されます)。

table_aフィールドにインデックスがありdateます。

どうやら SQL_CALC_FOUND_ROWSはインデックスの使用を防ぐことができます:

したがって、この単純なテストから明らかな結論は、クエリの WHERE/ORDER 句に適切なインデックスがある場合、SQL_CALC_FOUND_ROWS を使用して 1 つのクエリを使用するよりも、2 つの個別のクエリを使用する方がはるかに高速であることです。

私はこれを確認しました。SQL_CALC_FOUND_ROWSが含まれている場合、インデックスは使用されません。

ただし、SQL_CALC_FOUND_ROWSが使用されていない場合は、日付フィールドのインデックスが使用されます。

クエリから削除せずにクエリを高速化する方法はありSQL_CALC_FOUND_ROWSますか?

MySQL バージョン 5.0.51a-3ubuntu5.1-log を使用しています。