MySQL データベースの一般的なテクニックは何ですか?

1. サーバーの種類はどのように選択すればよいですか?

MySQL サーバー設定ウィンドウの各パラメータの意味は次のとおりです。

このオプションは、サーバーの構成タイプを指定するために使用されます。このオプションの右側にある下ボタンをクリックすると、3 つのオプションが表示されます。

3 オプションの具体的な意味は次のとおりです。

このオプションは、開発用の典型的な個人用デスクトップ ワークステーションを表します。マシン上で複数のデスクトップ アプリケーションが実行されていると仮定します。最小限のシステム リソースを使用するように MySQL サーバーを構成します。

サーバー マシン (サーバー): このオプションはサーバーを表します。MySQL サーバーは、FTP、電子メール、Web サーバーなどの他のアプリケーションと一緒に実行できます。 MySQL サーバーは、適切な割合のシステム リソースを使用するように構成されています。

D dedicatedMySQL Server Machine (専用 MySQL サーバー): このオプションは、MySQL サービスのみを実行するサーバーを表します。他のアプリケーションは実行されていないと想定されます。 MySQL サーバーは、利用可能なすべてのシステム リソースを使用するように構成されています。初心者の場合は、システム リソースの使用量が少ない [開発マシン] オプションを選択することをお勧めします。

2. MySQL で特殊文字を使用するにはどうすればよいですか?

一重引用符 (')、二重引用符 (")、バックスラッシュ () およびその他の記号など、これらの記号は MySQL に直接入力して使用することはできません。そうしないと、予期しない結果が生じます。MySQL では、これらの特殊文字はエスケープ文字と呼ばれます。入力するときはバックスラッシュ記号 ('') で始める必要があります。そのため、一重引用符と二重引用符を使用する場合は、それぞれ (') または (") を入力する必要があります。バックスラッシュを入力する場合は、 () を入力する必要があります。その他の特殊文字には、キャリッジ リターン ()、ライン フィード ()、タブ (ab)、バックスペース () などが含まれます。これらの特殊文字をデータベースに挿入する場合は、エスケープする必要があります。

3. MySQL は大文字と小文字を区別した文字列比較をどのように実行しますか?

MySQL は Windows プラットフォームでは大文字と小文字が区別されないため、文字列比較関数では大文字と小文字が区別されません。大文字と小文字を区別した比較を実行するには、文字列の前にキーワード BINARY を使用します。たとえば、デフォルトでは、'a'='A' の戻り結果は 1 です。BINARY キーワードが使用されている場合、BINARY'a'='A' の結果は 0 です。大文字と小文字が区別される場合、'a'と「A」は同じではありません。

MySQL ステートメント最適化スキル

MySQL データベースのパフォーマンスの最適化は、MySQL データベースの開発のための唯一の方法であり、MySQL データベースのパフォーマンスの最適化は、MySQL データベースの進歩の証人でもあります。以下は、MySQL ステートメントの最適化の概要です。いくつかのヒント:

1. where 句では != または <> 演算子を使用しないようにしてください。使用しないと、エンジンがインデックスの使用を断念し、フルテーブルスキャン。

クエリを最適化するには、テーブル全体のスキャンを可能な限り回避する必要があります。次に、where と order by に関係する列にインデックスを構築することを優先する必要があります。

3. where 句でフィールドの null 値を判断しないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のようなテーブル全体のスキャンを実行します:

select id from t where num is null

num にデフォルト値 0 を設定し、テーブルの num 列に null 値がないことを確認してから、次のようにクエリを実行します。

select id from t where num=0

4. 条件を接続するために where 句で または を使用しないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のようなテーブル全体のスキャンを実行します。

select id from t where num=10 or num=20

次のようにクエリできます:

select id from t where num=10

union all

select id from t where num=20

5. 次のクエリでも、完全なテーブル スキャンが行われます: (パーセント記号の前に置くことはできません)

select id from t where name like '�c%'

効率を向上させるために、全文検索を検討してください。

6. in と not in も注意して使用する必要があります。そうしないと、次のようにテーブル全体のスキャンが行われることになります。

select id from t where num in(1,2, 3)

連続値の場合、 between を使用できる場合は in を使用しないでください:

select id from t where num between 1 and 3

7. を使用する場合は、in を使用しないでください。 where 句内のパラメータも完全なテーブル スキャンになります。 SQL はローカル変数を実行時にのみ解決するため、オプティマイザはアクセス プランの選択を実行時まで延期できず、コンパイル時に選択を行う必要があります。アクセス プランがコンパイル時に構築され、変数の値が不明な場合、この値はインデックス選択の入力として使用できません。たとえば、次のステートメントはテーブル全体のスキャンを実行します:

select id from t where num=@num

これを変更して、クエリでインデックスを使用するように強制できます:

select id from t with(index (インデックス名)) where num=@num

8. where 句内のフィールドに対して式操作を実行しないようにしてください。これにより、エンジンが使用を断念します。インデックスを削除し、テーブル全体のスキャンを実行します。例:

select id from t where num/2=100

は次のように変更する必要があります:

select id from t where num=100*2

9. where 句内のフィールドに対して関数操作を実行しないようにしてください。これにより、エンジンがインデックスの使用を断念し、テーブル全体のスキャンが実行されます。例:

select id from t where substring(name,1,3)='abc' – abc で始まる名前 ID

select id from t where datediff(day,createdate,' 2005-11-30')=0–'2005-11-30'生成された id

は次のように変更する必要があります:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate

10. where 句の「=」の左側で関数、算術演算、その他の式演算を実行しないでください。実行しないと、システムがインデックスを正しく使用できない可能性があります。

11. インデックス フィールドを条件として使用する場合、インデックスが複合インデックスの場合、インデックスの最初のフィールドを条件として使用して、システムが確実にインデックスを使用する必要があります。そうでない場合、インデックスはフィールドの順序はインデックスの順序とできる限り一致する必要があります。

12. 意味のないクエリは書かないでください。たとえば、空のテーブル構造を生成する必要がある場合:

selectcol1,col2 into #t from t where 1=0

This クラス コードは結果セットを返しませんが、システム リソースを消費します。これを次のように変更する必要があります:

create table #t(…)

13。何度も良い選択:

select num from a where num in(select num from b)

次のステートメントに置き換えます:

select num from a where names(select 1 from b where num=a.num)

14. すべてのインデックスがクエリに有効であるわけではありません。SQL はテーブル内のデータに基づいてクエリを最適化します。インデックス列にデータが重複している場合、SQL クエリではインデックスが使用されない可能性があります。たとえば、テーブルに性別フィールドがあり、ほぼ半数が男性、半数が女性である場合、インデックスが性別に基づいて構築されている場合でも、クエリの効率には影響しません。

15. インデックスは多ければ多いほど良いです。インデックスにより、対応する選択の効率は向上しますが、挿入または更新中にインデックスが再構築される可能性があるため、挿入と更新の効率も低下します。インデックス作成には慎重な検討が必要であり、状況によって異なります。 1 つのテーブルに 6 つを超えるインデックスを作成しないことが最善ですが、この数を超える場合は、使用頻度の低い列にインデックスを作成する必要があるかどうかを検討する必要があります。

16. クラスター化インデックス データ列の順序は、テーブル レコードの物理的な格納順序であるため、クラスター化インデックス データ列の更新はできるだけ避けてください。列の値が変更されると、テーブル レコード全体の順序が変更されます。かなりのリソースを消費します。アプリケーション システムがクラスター化インデックスのデータ列を頻繁に更新する必要がある場合は、インデックスをクラスター化インデックスとして構築する必要があるかどうかを検討する必要があります。

17. 数値フィールドを使用するようにしてください。フィールドに数値情報のみが含まれる場合は、文字フィールドとして設計しないようにしてください。これにより、クエリと接続のパフォーマンスが低下し、ストレージのオーバーヘッドが増加します。エンジンはクエリと結合の処理時に文字列内の各文字を 1 つずつ比較するため、数値型を 1 つずつ比較するのではなく、1 回だけ比較するだけで済みます。

18. char/nchar の代わりに varchar/nvarchar をできるだけ使用してください。これは、第一に、可変長フィールドの記憶領域が小さく、記憶領域を節約できるためです。第 2 に、クエリの検索効率が比較的高くなります。小さなフィールドは高い、明らかに高い。

19. select * from t をどこでも使用せず、「*」を特定のフィールド リストに置き換え、未使用のフィールドを返さないでください。

20. 一時テーブルの代わりにテーブル変数を使用してみてください。テーブル変数に大量のデータが含まれている場合は、インデックスが非常に制限される (主キー インデックスのみ) ことに注意してください。

21. システム テーブル リソースの消費を減らすために、一時テーブルを頻繁に作成および削除することは避けてください。

22. 一時テーブルは使用できないわけではありません。一時テーブルを適切に使用すると、たとえば、大きなテーブルやよく使用されるテーブル内の特定のデータ セットを繰り返し参照する必要がある場合など、特定のルーチンの効率が向上します。ただし、1 回限りのイベントの場合は、エクスポート テーブルを使用することをお勧めします。

23. 一時テーブルを作成するときに、一度に挿入されるデータの量が多い場合は、create table の代わりに select into を使用すると、大量のログが発生して速度が向上するのを避けることができます。システムを容易にするために、データの量は大きくありません。テーブル リソースの場合は、最初にテーブルを作成してから、それを挿入する必要があります。

24. 一時テーブルを使用する場合、ストアド プロシージャの最後にすべての一時テーブルを明示的に削除する必要があります。最初にテーブルを切り捨ててから、テーブルを削除します。これにより、システム テーブルの長期ロックを回避できます。 。

25. カーソルは効率が悪いため、カーソルの使用は避けてください。カーソルで操作するデータが 10,000 行を超える場合は、データの書き換えを検討してください。

26. 大規模なトランザクション操作を避け、システムの同時実行性を向上させるようにしてください。

以上がMySQL データベースの一般的なテクニックは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。