MySQLデータベースの前処理（プリペアドステートメント）パフォーマンステストのご紹介-mysql チュートリアル-php.cn

無料学習の推奨事項: mysql ビデオチュートリアル

#1. 前処理は何を行いますか

# データベースステートメントを送信すると、そのステートメントはデータベースサービスに到達し、データベースサービスは SQL ステートメント (構文など) を解析する必要があります。チェックすると、クエリ条件が最初に最適化されてから実行されます。前処理では、簡単に言えば、クライアントとデータベースサービスの間の元の対話が 2 回に分割されます。まず、データベースステートメントを送信し、最初にデータベースサービスにステートメントを解析させます。次に、パラメータを送信し、ステートメントを呼び出して実行します。このようにして、複数回繰り返し実行されるステートメントの場合、データベースステートメントを一度送信して解析し、解析されたばかりのステートメントを継続的に呼び出して実行できます。これにより、同じステートメントを複数回解析する時間を節約できます。効率を向上させるという目的を達成するため。

前処理ステートメントはプレースホルダー (プレースホルダー) をサポートしており、パラメーターはプレースホルダーをバインドすることによって送信されます。非常に重要な点は、プレースホルダーにバインドできるのは値のみであり、SQL ステートメントの一部のキーワードではないということです。たとえば、ステートメント: 「select * from Student where students.id = ?」。プレースホルダ (?) が "1 or 1=1" の場合、"1 or 1=1" は値とみなされ、つまり " 記号で囲まれたものとみなされます。最終的に、この不正なステートメントはエラーになります。これにより、SQL インジェクション (SQL インジェクション) の脆弱性が回避されます。

前処理メカニズムの 3 つの主なステップ:

1. ステートメントを前処理します

2. ステートメントを実行します

3. 前処理ステートメントを破棄します。

2. `performance_schema`.`prepared_statements_instances` テーブルの概要

SQL スクリプトを実行します: '%prepare%' のようなグローバル変数を表示します。「

performance_schema_max_prepared_statement_instances

」 というシステム変数が表示されます。値 0 は、プリペアドステートメントのパフォーマンスデータレコードテーブルが有効になっていないことを意味します `performance_schema`.`prepared_statements_instances`; -1 は、レコードの数が動的に処理されることを意味します; 他の正の整数値は、performance_schema_max_prepared_statement_instances を表します最大レコード数項目数。テーブル `performance_schema`.`prepared_statements_instances` とは何ですか?これは、準備されたステートメントのいくつかの基本情報とパフォーマンスデータを記録するために使用されます。たとえば、準備済みステートメントの ID、準備済みステートメントの名前、準備済みステートメントの具体的なステートメントの内容、準備済みステートメントの実行回数、各実行にかかる時間、各準備済みステートメントが実行されたスレッド ID などです。ステートメントが属するなど準備されたステートメントを作成すると、データの一部がこのテーブルに挿入されます。 Prepared Statement は接続に基づいており、接続が切断されると、Prepared Statement は自動的に削除されます。ただし、「performance_schema」.「prepared_statements_instances」テーブルはグローバルであり、データベース接続とは何の関係もありません。このデータを使用すると、1. コード内で実行されるステートメントが実際に前処理されているかどうか、2. 前処理されたステートメントの実行を理解することで、ビジネスでステートメントを前処理する必要があるかどうかを判断できます。

3. qt prepare 関数の説明

私自身のプロジェクトのニーズに基づいて、このテストのクライアントコードは Qt を使用します。ここには重要な関数、QSqlQuery クラスの prepare 関数が記録されています。準備関数を呼び出すことは、準備されたステートメントを作成するコマンドをデータベースに送信することです。これは、通話中にデータベースサービスとの対話が行われることを意味します。同じ QSqlQuery クラスオブジェクトが 2 回目に prepare を呼び出すと、最初の prepare 呼び出しで作成されたプリペアドステートメントは削除され、2 つのプリペアドステートメントがまったく同じである場合でも、プリペアドステートメントが作成されることに注意してください。同じ。 QSqlQuery の exec 関数を呼び出すと、QSqlQuery によって以前に作成された準備済みステートメントも削除されます。したがって、クエリの最後に接続が閉じられるか、クエリが他のステートメントを実行すると、その結果、`performance_schema`.`prepared_statements_instances` テーブルには関連するプリペアドステートメントのレコードがなくなり、プリペアドステートメントが作成されたと誤って信じられます。準備されたステートメントが失敗しました。実際、Qt のアプローチにより、準備されたステートメントを手動で削除する手間も省けます。

4. 実験的推測

定期的に実行されるステートメントと前処理後に実行されるステートメントの違いは、複数実行の場合、前処理されたステートメントは Parse のみを必要とすることです。 SQL ステートメントを 1 回実行した後、パラメーターの送信とパラメーターのバインドにさらに時間を費やします。準備されたステートメントは結果を返すときにバイナリ転送プロトコルを使用しますが、通常のステートメントはテキスト形式の転送プロトコルを使用します。そこで、以下のような推測を立てて検証してみます。

1. 単純な文を実行する場合、通常の実行と前処理の実行で性能に大きな差はありません。準備されたステートメントは、複雑なステートメントが繰り返し実行される場合にのみ利点を発揮します。

2. クエリ結果セットが大量のデータである場合、準備されたステートメントはパフォーマンス上の利点を示します。

5. 実験データ記録

ですの .taskId ##9 は select * from task where task.taskId = ? 10#11 isselect * from task a LEFT JOIN task_file b ON a.taskId = b.task_id where a.taskName like '%s%' and b.file_id > ; 100000 および b.file_id No2100036612いいえselect * from task a LEFT JOIN task_file b ON a.taskId = b.task_id where a.taskName like '%s%' and b.file_id > 100000 and b.file_id No21000380

6. 結論

実験データの結果は私が予想していたものとは少し異なりましたが、テストコードとテストプロセスを繰り返し検証した結果、次のことが確認されました。テスト自体には問題ありません。実験データを尊重して、次の結論を導き出します。

1. 実験 5 と 6 を比較し、実験 11 と 12 を比較することにより、推測 1 が間違っていると結論付けることができます。結論は次のようになります。単純なステートメントと複雑なステートメントでは、MySQL の前処理と通常のクエリの間にパフォーマンスに大きな違いはありません。

2. 実験 1 と実験 2 を比較し、実験 7 と実験 8 を比較すると、推測 2 は間違っていると結論付けることができます。結論は次のようになります。

MySQL 前処理の結果と従来のクエリとの間には、データ送信におけるパフォーマンスに大きな差はありません。

3. さらに、リモートデータベースとローカルデータベースの実験データを比較します。 MySQL データベースは、ローカルでのデータ操作のパフォーマンスを大幅に向上させると結論付けることができます。

#関連する無料学習の推奨事項:
mysql データベース(ビデオ)

シリアル番号	前処理するかどうか	ステートメント	リモートデータベースかどうか	返されるデータの量	各実験ステートメントの合計実行数	3 つの実験の平均合計消費時間/単位はミリ秒
1	は	select * from task where (?)	の task.taskId は	1000	1000	69822
2	No	select * from task where task (arr)	is	1000	1000	66778
3	is	select * from task where task.taskId = ?	=	1	1000	1260
4	No	select * from task where task.taskId = id	Yes	1	1000	951
5	is	select * from タスク a LEFT JOIN task_file b ON a。 taskId = b.task_id ここで、「%s%」のような .taskName、b.file_id > 100000、および b.file_id	はい	2	1000	2130
6	いいえ	select * from task a LEFT JOIN task_file b ON a.taskId = b.task_id where a.taskName like '%s%' and b.file_id > 100000 and b.file_id	は	#2	1000	1480
7	Yes	select * from task where task.taskId in (?)	No	1000	1000	57051
8	No	select * from task where task.taskId in (arr)	No	1000	1000	56235
		#No	1	1000	217
No	select * from task where task.taskId = id	No	1	1000	204