サーバのスロークエリーログ

MySQLMariaDBAurora

MySQLファミリーは両方を提供します。mysql.slow_logが実行を（その時間、ユーザ、そのままのテキストとともに）保持し、performance_schemaが形ごとの概要を保持します。

TiDB

TiDBは両方を別のテーブルから提供します。実行はCLUSTER_SLOW_QUERYから取り、これは各ノードのtidb-slow.logファイルを読みます（TiDBが自分で実行するクエリーは含みません）。形ごとの概要はSTATEMENTS_SUMMARYから取ります。

PostgreSQL

PostgreSQLは、クライアントが読める実行を保持しません。そのログはサーバのマシン上のファイルに書かれます。公開するのは集計で、pg_stat_statementsを通じて公開されるので、ここでは「SQL文ごと」が表示され、「エントリー」は表示されません。

SQL Server

SQL Serverにはスロークエリーログがありません。しきい値も、記録された実行もありません。保持しているのは、何もオンにしなくても常に、キャッシュ内の各プランの集計で、それが「SQL文ごと」に表示されます。「エントリー」は表示されません。

Oracle

Oracleにはスロークエリーログがありません。サーバのしきい値も、1件ずつ記録された実行もありません。読むのはSQL文のキャッシュ（V$SQL）で、ここに残っている間は各SQL文の数値を常に保持しています。「エントリー」はSQL文ごとに1行で、その平均の実行（時間、CPU、読み取り、行数を実行回数で割ったもので、横に実行回数を表示）を示し、「SQL文ごと」は形でまとめた概要を示します。これは履歴ではありません。キャッシュから外れたSQL文はその数値とともに消え、再起動で空になります。SYSとSYSTEMの内部クエリーは除外されます。ただし、それらのアカウントでサインインしている場合の自分のクエリーは除きます。V$SQLを読むにはディクショナリの権限（SELECT_CATALOG_ROLEまたはSELECT ANY DICTIONARY）が必要で、なければ画面にサーバのエラーが表示されます。AWRとDBA_HIST_*ビューは照会しません。Oracleの有償のパックが必要だからです。

ClickHouse

ClickHouseは両方をsystem.query_logから提供します。実行は、いま実行したものがすでに含まれるようSYSTEM FLUSH LOGSの直後に読み、形ごとの概要も同じテーブルから取ります。実行には失敗したものも含まれ、そのエラーは専用の列に入ります。時間の後には読み取ったバイト数とメモリーが並び、時刻はサーバの時計です。デフォルトでオンの「Calíope自身のものを非表示」は、Calíopeが自分で照会するものを隠しますが、エディタで自分が書いたものは決して隠しません。

MySQLMariaDBAurora

しきい値は秒単位（long_query_time）で、書き込み先はmysql.slow_logテーブル、サーバのファイル、その両方から選びます（log_output）。クライアントから読めるのは、テーブルに書かれたものだけです。

驚かれることが2つあります。ここで行った変更はサーバの再起動後には残りません（そのためには設定ファイルに書きます）。また、すでに開いている接続には届きません。Calíopeの接続も含め、生きているセッションはリサイクルされるまで前の値で計測し続けます。

Aurora

Amazon Auroraでは、これらの設定はサーバではなくクラスタのパラメータグループにあるので、ここではコントロールの代わりに注記が表示されます。ログを空にすることはできます。サーバ自身がmysql.rds_rotate_slow_logで行います。

TiDB

しきい値はtidb_slow_log_thresholdで、サーバはそれをミリ秒で保持します。ここではほかのエンジンと同じように秒で入力し、最後の一覧にはサーバの値が単位付きで表示されます。long_query_timeは存在しますが、何も制御しません。TiDBでは、負の値は一周して、何も記録されないほど高いしきい値になります。

書き込み先は選べません。TiDBは常に各ノードのファイルに書き、それをテーブルとして公開します。ここで行った変更は、Calíopeの接続も含め、そのノードへのすべての接続にすぐに届き、ノードが再起動するまで続きます。再起動すると設定の値に戻ります。

PostgreSQL

しきい値はミリ秒単位（log_min_duration_statement）で、ここで行った変更は残ります。ALTER SYSTEMで書き込まれ、サーバが設定を読み込み直します。

ただし、何も言わずにそれより優先されるソースがあります。値がサーバの起動時のコマンドラインから来ている場合や、このデータベース、このロール、このセッションの設定から来ている場合、書き込みは受け付けられ、ファイルは新しい値になりますが、有効なのは古い値のままです。そのため、下の一覧の最初の変数は「しきい値の出所」になっています。どこで変更すべきかを示すのはこの値です。出所がそれらのどれかのときは、ここにはコントロールではなく注記が表示されます。

書き込み先は選べません。PostgreSQLは常に自分のログ、つまりサーバのマシン上のファイルに書きます。

SQL Server

SQL Serverには調整するものがありません。プランキャッシュは常に集計を取り、しきい値も選べる書き込み先もありません。そのため、しきい値のカードは表示されず、コントロールの代わりに注記が表示されます。読む内容はサーバのメモリーにあるので、サーバが再起動すると失われ、キャッシュから外れたプランはその数値も一緒に持っていきます。optimize for ad hoc workloadsがオンのときは、1回限りのクエリーは2回目の実行で初めて入ります。

Oracle

Oracleでは、しきい値はCalíopeのもので、サーバのものではありません。読み取り時に各SQL文の平均の実行に適用され、このプロファイルに保存されます。変更してもサーバには何も触れず、次の読み取りから適用されます。キャッシュは時間をマイクロ秒で数えますが、しきい値は秒です。変更していなければ1秒です。スイッチはなく（キャッシュはオフにできません）、選べる書き込み先もありません。読む内容はサーバのメモリーにあります。

ClickHouse

サーバはしきい値をミリ秒で保持します（log_queries_min_query_duration_ms）が、ここでは秒で表示され、書き込み先は常にsystem.query_logです。スイッチとしきい値はALTER USER … MODIFY SETTINGSで自分のアカウントに保存され、そのアカウントのクエリーに次のものから適用されます。ほかの人のクエリーには適用されません。アカウントがサーバの設定で定義されているか、ALTER USERの権限がない場合は、コントロールの代わりに注記が表示されます。ログを空にするのはTRUNCATE TABLE system.query_logで、サーバ全体に対して行われます。

MySQLMariaDBAurora

performance_schemaが公開し、リテラルは?になります。MariaDBではオフで始まります。このビューに概要がないと表示されても、スロークエリーがないわけではありません。performance_schemaがOFFなのです。サーバの稼働中にはオンにできません。設定ファイルに書き、サーバを再起動する必要があります。

TiDB

STATEMENTS_SUMMARYから取り、リテラルは?と表示されます。起動から累積はしません。現在のウィンドウで、サーバはtidb_stmt_summary_refresh_interval秒ごと（デフォルトは1800）にそれを閉じて開き直すので、呼び出し回数はそのウィンドウの開始から数えられます。概要がオフ（tidb_enable_stmt_summary）なら、再起動なしにSET GLOBALでオンにできます。「統計をリセット」は表示されません。それを空にするSQL文がないからです。

PostgreSQL

pg_stat_statementsが公開し、リテラルは$1になります。必要なものが2つあり、どちらもアプリの外にあります。shared_preload_librariesにあらかじめ読み込んだライブラリ（サーバの再起動が必要）と、このデータベースに作成した拡張機能（データベースごとに1回）です：

CREATE EXTENSION pg_stat_statements;

拡張機能を作成してもライブラリが読み込まれていなければ、ビューは存在しても何も集めません。これは2つの別々の状態で、ツールはいまどちらなのかを示します。

SQL Server

sys.dm_exec_query_statsから取り、クエリーの形であるquery_hashでまとめます。表示されるテキストは、プレースホルダの入った形ではなく、その実行の1つのもので、リテラルもそのままです。読むにはVIEW SERVER STATE権限が必要で、なければビューにサーバのエラーが表示されます。「統計をリセット」は表示されません。この概要を消去するのはDBCC FREEPROCCACHEで、それはサーバ全体のプランを捨ててしまうので、ここからは行いません。

Oracle

V$SQLから取り、FORCE_MATCHING_SIGNATUREでまとめます。リテラルだけが違う2つのクエリーは1つの行になり、表示されるテキストはその1つのものです。その署名がないSQL文（PL/SQLブロック、DDL）はSQL_IDでまとめます。概要にはしきい値を適用せず、最大値はまとめたものの中でもっとも遅い平均の実行です。キャッシュは各実行を保持しないからです。「統計をリセット」も、「エントリー」の「ログを空にする」も表示されません。どちらもサーバ全体の共有キャッシュを空にすることになるからです。

ClickHouse

system.query_logから取り、normalized_query_hashでまとめます。リテラルだけが違う2つのクエリーは1つの行になり、表示されるテキストはその1つのものです。「統計をリセット」はその同じテーブルを空にするので、実行も一緒に消え、確認のダイアログでもそう伝えます。

MySQLMariaDBAuroraClickHouse

実行してから「プロファイル」を押すとフェーズごとの内訳が表示され、実行計画ビューアでエンジンに実行計画を尋ねることもできます。

PostgreSQLSQL ServerOracle

実行計画ビューアでエンジンに実行計画を尋ねます。フェーズごとの内訳である「プロファイル」はMySQLファミリーのもので、ここではエディタに表示されません。

TiDB

実行計画ビューアでエンジンに実行計画を尋ねます。フェーズごとの内訳である「プロファイル」はエディタに表示されません。TiDBにはないからです。

MySQLMariaDBAuroraPostgreSQLTiDB

また、SQL文ごとの概要から届くのは、値の代わりにプレースホルダが入った正規化された形です。実行する前に、自分の値を入れる必要があります。

SQL ServerClickHouseOracle

SQL文ごとの概要から届くのは、その実行の1つのテキストで、その実行の値が入っています。その行は、同じ形のすべての実行を代表しています。

MySQLMariaDBAurora

MySQL、MariaDB、Auroraでは、両方のボタンを使えます。

PostgreSQL

PostgreSQLでは、統計のリセットだけを使えます。

ClickHouse

ClickHouseでは両方を使え、統計をリセットすると実行も削除されます。同じテーブルだからです。

SQL ServerOracle

SQL ServerとOracleでは、どちらも提供されません。

TiDB

TiDBでは、どちらも提供されません。ログは各ノードのファイルで、概要はウィンドウごとに自動で新しくなるからです。