集める！面接で使用される、MySQL 面接の一般的な質問

以下は、面接や調査でよく遭遇する MySQL に関する質問の一部です。 SQL ステートメントの最適化の例: 1) where 句で != または 演算子を使用しないようにしてください。使用しないと、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。 2) where 句でフィールドの null 値を判断しないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のようにテーブル全体のスキャンを実行します。 select id from t where num is null

[関連トピック]推奨事項: mysql 面接の質問 (2020)】

1. 主キー スーパー キー候補キー外部キー

主キー:

データベーステーブルに保存されたデータオブジェクト。 データ列には主キーを 1 つだけ持つことができます。主キーの値を欠落させることはできません。つまり、null にすることはできません。

スーパーキー:

関係内のタプルを一意に識別できる属性のセットは、リレーショナル スキーマのスーパー キーと呼ばれます。属性はスーパーキーとして使用でき、複数の属性を組み合わせてスーパーキーとして使用することもできます。 スーパーキーには候補キーと主キーが含まれます。

候補キー:

は、最小スーパーキー、つまり、冗長な要素のないスーパーキーです。

外部キー:

あるテーブル内に存在する別のテーブルの主キーを、このテーブルの外部キーと呼びます。

2. データベーストランザクションの4つの特徴と意味

データベーストランザクショントランザクションを正しく実行するための4つの基本要素。 ACID、原子性、対応性、分離性、耐久性。

原子性: トランザクション全体のすべての操作は完了するか完了しないかのどちらかであり、中間リンクで停滞することは不可能です。トランザクションの実行中にエラーが発生した場合は、トランザクションがまったく実行されなかったかのように、トランザクションが開始される前の状態にロールバックされます。
一貫性: トランザクションの開始前とトランザクションの終了後に、データベースの整合性制約に違反しません。
分離: トランザクションを分離された状態で実行し、特定の時点でシステムによって実行される唯一の操作であるように見せます。同時に実行され、同じ機能を実行する 2 つのトランザクションがある場合、トランザクション分離により、システム内の各トランザクションは、そのトランザクションのみがシステムを使用していると認識されます。このプロパティはシリアル化と呼ばれることもあります。トランザクション操作間の混乱を避けるために、同じデータに対するリクエストが同時に 1 つだけになるように、リクエストをシリアル化または逆シリアル化する必要があります。
永続性: トランザクションの完了後、トランザクションによってデータベースに加えられた変更はデータベースに永続化され、ロールバックされません。

3. ビューの役割は変更できますか?

ビューは、データを含むテーブルとは異なり、使用時にデータを動的に取得するクエリのみを含み、列やデータは含まれません。ビューを使用すると、複雑な SQL 操作を簡素化し、特定の詳細を非表示にし、データを保護できます。ビューを作成すると、テーブルと同じように使用できます。

ビューにインデックスを付けることはできず、ビュー自体に order by がある場合、ビュー上の order by は上書きされます。
ビューの作成: ビューの作成 これは、データの取得を簡素化し、保護するために使用されます。更新には使用されず、ほとんどのビューは更新できません。

4.drop、delete、truncateの違い

dropはテーブルを直接削除し、truncateはテーブル内のデータを削除し、再度挿入するとIDは1から増加します。 where 句。

(1) DELETE文による削除処理は、テーブルから1行ずつ削除すると同時に、その行の削除操作をロールバック操作のトランザクション記録としてログに保存します。 TRUNCATE TABLE はテーブルからすべてのデータを一度に削除し、個々の削除操作レコードをログに記録しません。削除された行は復元できません。また、テーブルに関連する削除トリガーは、削除プロセス中にアクティブ化されません。実行速度が速い。

(2) テーブルとインデックスによって占有されるスペース。テーブルが TRUNCATE されると、テーブルとインデックスが占有する領域は元のサイズに復元され、DELETE 操作ではテーブルまたはインデックスが占有する領域は減りません。 Drop ステートメントは、テーブルによって占有されているすべてのスペースを解放します。

(3) 一般的には、drop > truncate >

(4) アプリケーション スコープ。 TRUNCATE は TABLE にのみ使用でき、DELETE はテーブルとビューに使用できます

(5) TRUNCATE と DELETE はデータのみを削除しますが、DROP はテーブル全体 (構造とデータ) を削除します。

(6) where なしで切り捨てて削除: データのみを削除しますが、テーブルの構造 (定義) は削除しません。drop ステートメントは、テーブル構造の制約 (constrain)、トリガー (トリガー) インデックス (インデックス) を削除します。依存します; テーブルに依存するストアド プロシージャ/関数は保持されますが、ステータスは無効になります。

(7) 削除ステートメントは DML (データ保守言語) であり、この操作はロールバック セグメントに配置され、トランザクションが送信された後にのみ有効になります。対応するティガーがある場合、実行中にトリガーされます。

(8) truncate とdrop は DLL (データ定義言語) であり、操作はすぐに有効になります。元のデータはロールバック セグメントに配置されず、ロールバックできません。

(9) バックアップがない場合は、次を使用します。削除および切り詰めは注意してください。一部のデータ行を削除するには、delete を使用し、影響範囲を制限する場所と組み合わせます。ロールバック セグメントは十分な大きさである必要があります。テーブルを削除するには、drop を使用します。テーブルを保持しながらテーブル内のデータを削除する場合は、truncate を使用します。トランザクションに関連している場合、または教師がトリガーをトリガーしたい場合は、引き続き削除を使用します。

(10) Truncate table table name は、次の理由により高速かつ効率的です。
truncate table は、WHERE 句のない DELETE ステートメントと機能的に同じです。どちらもテーブル内のすべての行を削除します。ただし、TRUNCATE TABLE は DELETE よりも高速で、使用するシステム リソースとトランザクション ログ リソースが少なくなります。 DELETE ステートメントは一度に 1 行を削除し、削除された行ごとにトランザクション ログにエントリを記録します。 TRUNCATE TABLE は、テーブル データの保存に使用されるデータ ページを解放することによってデータを削除し、解放されたページのみをトランザクション ログに記録します。

(11) TRUNCATE TABLE はテーブル内のすべての行を削除しますが、テーブル構造とその列、制約、インデックスなどは変更されません。新しい行を識別するために使用されるカウントは、その列のシードにリセットされます。 ID カウント値を保持したい場合は、代わりに DELETE を使用してください。テーブル定義とそのデータを削除する場合は、DROP TABLE ステートメントを使用します。

(12) FOREIGN KEY 制約によって参照されるテーブルの場合、TRUNCATE TABLE は使用できませんが、WHERE 句のない DELETE ステートメントを使用する必要があります。 TRUNCATE TABLE はログに記録されないため、トリガーをアクティブ化できません。

5. インデックスの動作原理と種類

データベース インデックスは、データベース テーブル内のデータの迅速なクエリと更新を支援する、データベース管理システム内の並べ替えられたデータ構造です。 インデックス実装は通常、B ツリーとそのバリアント B+ ツリーを使用します。

データベース システムは、データに加えて、特定の検索アルゴリズムを満たすデータ構造も維持します。これらのデータ構造は、これらのデータ構造に高度な検索アルゴリズムを実装できるように、何らかの方法でデータを参照 (ポイント) します。このデータ構造がインデックスです。

テーブルのインデックスの設定にはコストがかかります。まず、データベースの記憶領域が増加します。次に、データの挿入と変更に時間がかかります (それに応じてインデックスも変更されるため)。

この図は、考えられるインデックス作成方法の 1 つを示しています。左側には、合計 2 つの列と 7 つのレコードを持つデータ テーブルがあり、一番左はデータ レコードの物理アドレスです (論理的に隣接するレコードがディスク上で物理的に隣接している必要はないことに注意してください)。 Col2 の検索を高速化するために、右に示すように、各ノードにインデックス キー値と、対応するデータ レコードの物理アドレスへのポインターを含めることができます。 O(log_{2の二分探索} nの計算量内で対応するデータが得られる)。

インデックスを作成すると、システムのパフォーマンスが大幅に向上します。

まず、一意のインデックスを作成することで、データベーステーブル内のデータの各行の一意性を保証できます。

2 番目に、データの取得を大幅に高速化できます。これがインデックスを作成する主な理由でもあります。

3 番目に、テーブル間の接続を高速化できます。これは、データの参照整合性を達成する上で特に意味があります。

4 番目に、データの取得にグループ化句と並べ替え句を使用すると、クエリでのグループ化と並べ替えの時間も大幅に短縮できます。

5 番目に、インデックスを使用すると、クエリ プロセス中に最適化非表示機能を使用してシステムのパフォーマンスを向上させることができます。

「インデックスを追加するとたくさんの利点があるのに、テーブル内のすべての列にインデックスを作成しないのはなぜですか?」と疑問に思う人もいるかもしれません。なぜなら、インデックスの追加には多くのデメリットもあるためです。

まず、インデックスの作成と維持には時間がかかり、データ量が増えるとこの時間も長くなります。

第 2 に、インデックスはデータ テーブルが占有するデータ スペースに加えて、一定量の物理スペースも占有する必要があります。クラスター化インデックスを構築する場合、必要なスペースはさらに大きくなります。

3 番目に、テーブル内のデータを追加、削除、変更する場合、インデックスを動的に維持する必要があるため、データのメンテナンス速度が低下します。

インデックスはデータベーステーブルの特定の列に基づいて構築されます。インデックスを作成するときは、どの列にインデックスを作成できるか、どの列にインデックスを作成できないかを考慮する必要があります。 一般的に、インデックスは次の列に作成する必要があります: 頻繁に検索される列では、検索を高速化できます。主キーとして機能する列では、列の一意性が強化され、テーブル内のデータの配置が整理されます。 ; 結合でよく使用される列にインデックスを作成します。これらの列は主に外部キーであり、インデックスがソートされており、指定された範囲に基づいて検索する必要があることが多い列にインデックスを作成します。連続; in 頻繁にソートが必要な列にインデックスを作成します。インデックスはすでにソートされているため、クエリはインデックスのソートを使用して、WHERE 句でよく使用される列にインデックスを作成します。状況判断が早くなります。

また、インデックスを作成してはいけない列もあります。

一般的に、インデックスを作成すべきではない列には次の特徴があります:

まず、クエリでほとんど使用または参照されない列にはインデックスを作成すべきではありません。これは、これらの列がほとんど使用されないため、インデックスを作成してもしなくてもクエリ速度は向上しないためです。逆に、インデックスの追加により、システムのメンテナンス速度が低下し、必要なスペースが増加します。

第 2 に、データ値が少ない列のインデックスは増加させるべきではありません。これは、クエリ結果ではこれらの列 (人事テーブルの性別列など) の値が非常に少ないため、結果セット内のデータ行がテーブル内のデータ行の大部分を占めるためです。テーブル内で検索する必要があるデータ 行の割合が膨大です。インデックスを増やしても、検索が大幅に高速化されるわけではありません。

第三に、テキスト、イメージ、ビットのデータ型として定義された列にはインデックスを追加しないでください。これは、これらの列のデータ量が非常に大きいか、値が非常に少ないためです。

4番目に、変更パフォーマンスが検索パフォーマンスよりもはるかに大きい場合、インデックスは作成されるべきではありません。

修正性能と検索性能は相反するからである。インデックスを追加すると、検索パフォーマンスは向上しますが、変更パフォーマンスは低下します。インデックスを減らすと、変更パフォーマンスは向上しますが、検索パフォーマンスは低下します。したがって、変更パフォーマンスが検索パフォーマンスよりもはるかに高い場合は、インデックスを作成しないでください。

データベースの機能に応じて、データベースデザイナーでは

ユニークインデックス、主キーインデックス、クラスター化インデックスの3種類のインデックスを作成できます。

一意のインデックス

一意のインデックスは、2 つの行が同じインデックス値を持つことを許可されないインデックスです。

ほとんどのデータベースでは、既存のデータに重複するキー値がある場合、新しく作成した一意のインデックスをテーブルに保存することはできません。データベースは、テーブル内に重複するキー値を作成する新しいデータの追加を妨げる場合もあります。たとえば、従業員テーブル内の従業員の姓 (lname) に一意のインデックスが作成されている場合、2 人の従業員が同じ姓を持つことはできません。

主キー インデックス データベース テーブルには、多くの場合、テーブル内の各行を一意に識別する値を持つ 1 つの列または列の組み合わせがあります。この列はテーブルの主キーと呼ばれます。 データベース ダイアグラム内のテーブルの主キーを定義すると、特定のタイプの一意のインデックスである主キー インデックスが自動的に作成されます。インデックスでは、主キーの各値が一意である必要があります。また、クエリで主キー インデックスが使用される場合、データへの高速アクセスも可能になります。 クラスター化インデックス クラスター化インデックスでは、テーブル内の行の物理的な順序は、キー値の論理 (インデックス) 順序と同じです。 テーブルにはクラスター化インデックスを 1 つだけ含めることができます。

インデックスがクラスター化インデックスではない場合、テーブル内の行の物理的な順序はキー値の論理的な順序と一致しません。

クラスター化インデックスは通常、非クラスター化インデックスと比較して高速なデータ アクセスを提供します。

局所性原理とディスク先読み

記憶媒体の特性により、ディスク自体のアクセスはメインメモリよりもはるかに遅く、機械的な移動コストと相まって、ディスクのアクセス速度は多くの場合、遅くなります。 1 つはメイン メモリの数百パーセントであるため、効率を向上させるには、ディスク I/O を最小限に抑える必要があります。この目標を達成するために、ディスクは厳密にオンデマンドで読み取るのではなく、たとえ 1 バイトしか必要とされない場合でも、毎回事前に読み取りを開始し、この位置から一定の長さのデータを順番に読み取ります。メモリ。これの理論的根拠は、コンピューター サイエンスで有名な

局所性原理 です。つまり、データの一部が使用されると、通常は近くのデータがすぐに使用されます。通常、プログラム実行中に必要なデータは集中しています。 ディスクの順次読み取りは非常に効率的であるため (シーク時間が不要で、スピン時間が非常に短い)、先読みにより局所性のあるプログラムの I/O 効率が向上します。

先読みの長さは通常、ページの整数倍です。ページは、コンピュータが管理するメモリの論理ブロックであり、多くの場合、メイン メモリとディスク ストレージ領域は、各ストレージ ブロックを連続した同じサイズのブロックに分割します (多くのオペレーティング システムでは、ページ サイズは通常 4k)。メインメモリとディスクはページ単位でデータを交換します。プログラムによって読み取られるデータがメインメモリにない場合、ページフォールト例外がトリガーされ、システムはディスクに読み取り信号を送信し、ディスクはデータの開始位置を見つけます。 1 つ以上のページを逆方向に読み取ってメモリにロードすると、異常終了してプログラムは実行を続けます。

B-/+Tree インデックスのパフォーマンス分析

この時点で、最終的に B-/+Tree インデックスのパフォーマンスを分析できるようになります。

前述したように、インデックス構造の品質を評価するために、ディスク I/O の数が一般的に使用されます。 B ツリー分析から始めましょう。B ツリーの定義によれば、1 回の検索で最大 h 個のノードを訪問する必要があることがわかります。データベース システムの設計者は、ディスク先読みの原理を巧みに利用し、ノードのサイズを 1 ページに等しくなるように設定しました。これにより、各ノードは 1 つの I/O だけで完全にロードできるようになります。この目標を達成するには、B ツリーの実際の実装で次のテクニックを使用する必要があります:

新しいノードが作成されるたびに、スペースのページが直接適用され、ノードが物理的に保存されます。これらはすべてページごとに配置されているため、ノードに必要な I/O は 1 つだけです。

B-Tree での取得には最大でも h-1 個の I/O (ルートノード常駐メモリ) が必要で、漸近複雑度は O(h)=O(log_dN) です。 一般的な実際のアプリケーションでは、出次数 d は非常に大きな数で、通常は 100 を超えます。そのため、h は非常に小さくなります (通常は 3 以下)。

赤黒の木のような構造では、h は明らかにはるかに深くなります。論理的に近いノード (親と子) は物理的に遠く離れている可能性があり、局所性を利用できないため、赤黒ツリーの I/O 漸近複雑度も O(h) であり、効率は明らかにそれよりもはるかに悪くなります。 B ツリーの。

要約すると、B-Tree をインデックス構造として使用することは非常に効率的です。

6. 接続の種類

クエリ アナライザーで実行:
–テーブル table1、table2 を作成:
テーブル table1(id int, name varchar(10))を作成
テーブル table2(id int, スコア int)
table1 に挿入select 1,'lee'
table1 に挿入 select 2,'zhang'
table1 に挿入 select 4,'wang'
table2 に挿入 select 1,90
table2 に挿入 select 2,100
table2 に挿入 select 3,70
表に示されています
——————————————-
table1 | table2 |
——————————————-
id name |idスコア
1 lee |1 90|
2 zhang| 2 100|
4 wang|
————————————————-

以下はすべてクエリアナライザーで実行されます
1 . 外部結合
1. 概念: 左外部結合、右外部結合、または完全外部結合を含む

2. 左外部結合: 左外部結合
(1) 左外部結合の結果セットには、LEFT OUTER のすべての行が含まれます。結合列によって一致する行だけでなく、句で指定された左側のテーブル。左側のテーブルの行に右側のテーブルに一致する行がない場合、右側のテーブルのすべての選択リスト列は、関連する結果セット行で null になります。
(2)SQL文
select * from table1 left join table2 on table1.id=table2.id
————-result————-
idnameidscore
——————————
1lee190
2zhang2100
4wangNULLNULL
——————————
注: table1 のすべての句が含まれ、指定された条件に従って table2 の対応するフィールドを返し、準拠していないフィールドは null

3 として表示されます。右外部結合または右外部結合
(1) 右外部結合は、左外部結合の逆結合です。右側のテーブルのすべての行が返されます。右側のテーブルの行に左側のテーブルに一致する行がない場合、左側のテーブルには NULL が返されます。
(2)SQL文
select * from table1 right join table2 on table1.id=table2.id
————-result————-
idnameidscore
——————————
1lee190
2zhang2100
NULLNULL370
——————————
注: table2 のすべての句が含まれ、指定された条件に従って table1 の対応するフィールドを返し、準拠していないフィールドは null

4 として表示されます。 : 完全結合または完全外部結合
(1) 完全外部結合は、左右のテーブルのすべての行を返します。行に別のテーブルに一致する行がない場合、他のテーブルの選択リスト列には NULL 値が含まれます。 テーブル間に一致する行がある場合、結果セットの行全体にベーステーブルのデータ値が含まれます。
(2)SQL文
select * from table1 full join table2 on table1.id=table2.id
————-結果————-
idnameidscore
——————————
1lee190
2zhang2100
4wangNULLNULL
NULLNULL370
——————————
注: 左結合と右結合の合計を返します (上記の左結合と右結合を参照)

2. 概念: 内部結合join を使用します 比較演算子は結合する列の値の結合を比較します

2. 内部結合: join または inner join

3.sql ステートメント
select * from table1 join table2 on table1.id=table2。 id
————-結果————-
idnameidscore
——————————
1lee190
2zhang2100
——————————
注:
の列のみを返します条件を満たすtable1とtable2
4. 同等（以下と同じ実行効果）
A:select a.*,b.* from table1 a,table2 b where a.id=b.id
B:select * from table1 クロス結合 table2 where table1.id =table2.id (
注: 条件を追加する場合は、on ではなく、where のみを使用できます)3. クロス結合
(完了)
1. : WHERE 句のないクロス結合では、関係するテーブルの結合デカルト積が生成されます。最初のテーブルの行数と 2 番目のテーブルの行数を乗算すると、デカルト積の結果セットのサイズと等しくなります。 (table1 と table2 のクロス結合は 3*3=9 レコードを生成します)

2. クロス結合:
cross join (条件なし where...)
3.sql ステートメント
select * from table1cross join table2
————-結果————-
idnameidscore
——————————
1lee190
2zhang190
4wang190
1lee2100
2zhang2100
4wang2100
1lee370
2zhang370
4wang370
——— ———— — —
注: 3*3=9 レコードを返します。これは、デカルト積です

4。同等 (次の実行効果と同じ)
A: select * from table1, table2

7. データベースのパラダイム

1 第一正規形 (1NF)

リレーショナル データベースでは、第一正規形 (1NF) がリレーショナル モデルの基本要件です。 1NF) はリレーショナル データベースではありません。
いわゆる第一正規形 (1NF) は、データベース テーブルの各列が分割できない基本データ項目であることを意味します。同じ列に複数の値を含めることはできません。つまり、エンティティ内の属性は複数の値を持つことができません。または属性の重複。重複する属性が表示される場合は、新しいエンティティを定義する必要がある場合があります。新しいエンティティは重複する属性で構成されます。新しいエンティティと元のエンティティの間には 1 対多の関係があります。第 1 正規形 (1NF) では、テーブルの各行には 1 つのインスタンスのみに関する情報が含まれます。つまり、 第一正規形は繰り返しのない列です。

2 第 2 正規形 (2NF)

第 2 正規形 (2NF) は、第 1 正規形 (1NF) に基づいて確立されます。つまり、第 2 正規形 (2NF) を満たすには、次のことを行う必要があります。最初に第 1 正規形 ( 1NF) を満たします。第 2 正規形 (2NF) では、データベース テーブル内の各インスタンスまたは行を一意に区別できる必要があります。差別化を実現するには、通常、各インスタンスの一意の識別子を格納する列をテーブルに追加する必要があります。この一意の属性列は、主キー、主キー、主キーと呼ばれます。
第 2 正規形 (2NF) では、エンティティの属性が主キーに完全に依存していることが必要です。いわゆる完全な依存とは、主キーの一部にのみ依存する属性が存在することはできないことを意味します。存在する場合、この属性と主キーのこの部分を分離して、新しいエンティティを形成する必要があります。元のエンティティは 1 対多の関係です。差別化を実現するには、通常、各インスタンスの一意の識別子を格納する列をテーブルに追加する必要があります。つまり、第 2 正規形は、非主属性が主キーワードに部分的に依存しないということです。

3 第 3 正規形 (3NF)

第 3 正規形 (3NF) を満たすには、まず第 2 正規形 (2NF) を満たす必要があります。つまり、第 3 正規形 (3NF) では、データベース テーブルには、他のテーブルに既に含まれている非主キー情報が含まれていないことが必要です。例えば、部門情報テーブルがあり、各部門には、部門番号（dept_id）、部門名、部門プロフィール等の情報が含まれる。従業員情報テーブルに部門番号がリストされた後は、部門名、部門プロフィール、およびその他の部門関連情報を従業員情報テーブルに追加することはできません。部門情報テーブルが存在しない場合は、第 3 正規形 (3NF) に従って構築する必要があります。そうしないと、データの冗長性が高くなります。つまり、第 3 正規形は、属性が他の非主属性に依存しないということです。 (私の理解は冗長性を排除することです)

8. データベース最適化の考え方

このコースはデータベース最適化に関する MOOC から借りました。

1. SQL ステートメントの最適化

1) where 句で != または 演算子を使用しないようにしてください。そうしないと、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。
2) where 句のフィールドで null 値の判定を避けるようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のようなテーブル全体のスキャンを実行します。
select id from t where num is null
デフォルトは num 値 0 です。テーブルの num 列に null 値がないことを確認してください、そして次のようにクエリします:
select id from t where num=0
3) 多くの場合、in の代わりにexists を使用します。良い選択です
4) Where 句を使用して HAVING サブを置き換えます。HAVING はすべてのレコードを取得した後にのみ結果セットをフィルターするためです

2. インデックスの最適化

上記のインデックスを参照してください

3. データベース構造の最適化

1) パラダイム最適化: たとえば、冗長性の削除 (スペースの節約など) 2) アンチパラダイム最適化: たとえば、適切な冗長性の追加 (結合の削減) 3) テーブルの分割: データを分割する物理的に異なるディスクに分離されているため、異なるパーティションのデータを異なるディスク上のデータ ファイルに保存できます。この方法では、このテーブルをクエリするときに、テーブル全体をスキャンするのではなく、テーブル パーティションのみをスキャンする必要があるため、クエリ時間が大幅に短縮されます。また、異なるディスク上のパーティションにより、このテーブルのデータ送信も分散されます。ディスク I/O を慎重に構成すると、ディスク I/O のデータ転送競合が均等に分散されます。この方法は、大量のデータを含む timetable に使用できます。テーブル パーティションは月ごとに自動的に作成できます。
4) 分割は実際には垂直分割と水平分割に分けられます: ケース: 単純なショッピング システムには一時的に次のテーブルが含まれます: 1. 製品テーブル (データ量 100,000、安定) 2. 注文テーブル (データ量 200 万、増加傾向) ) 3. ユーザー テーブル (データ量: 100 万、増加傾向) mysql を例として水平分割と垂直分割を説明します。mysql が許容できる規模の範囲は、数百万から数千万の静的データです。垂直分割: 問題の解決: テーブル間の IO 競合は問題を解決しません: 単一テーブル内のデータ量の増加によって引き起こされるプレッシャー 解決策: 製品テーブルとユーザー テーブルを 1 つのサーバーに配置します。 水平分割: 問題の解決: 単一テーブル内のデータ量の増加によって引き起こされるプレッシャーは問題を解決しません: テーブル間の IO 競合
解決策: ユーザー テーブルは雄に分割されます。完了済みの注文と未完了の注文に分割されます。 完了済みの注文テーブルはサーバー上に配置されます。女性ユーザーテーブルはサーバー上に配置されます (女性は買い物が大好きです (笑)

4. サーバーハードウェアの最適化には多額の費用がかかります。

9. ストアド プロシージャとトリガーの違い

トリガーも SQL ステートメントのセットです。

両者の唯一の違いは、トリガーが EXECUTE ステートメントで呼び出されないことです。ユーザーが Transact を実行 - SQL ステートメントの実行を自動的にトリガー (アクティブ化) します。トリガーは、指定されたテーブル内のデータが変更されたときに実行されるストアド プロシージャです。

通常、トリガーは、異なるテーブル内の論理的に関連するデータの参照整合性と一貫性を強制するために作成されます。 ユーザーはトリガーをバイパスできないため、複雑なビジネス ルールを適用してデータの整合性を確保するために使用できます。トリガーはストアド プロシージャとは異なります。トリガーは主にイベント実行トリガーを通じて実行されますが、ストアド プロシージャはストアド プロシージャ名を通じて直接呼び出すことができます。 UPDATE、INSERT、DELETE などの操作が特定のテーブルに対して実行されると、SQLSERVER はトリガーによって定義された SQL ステートメントを自動的に実行するため、データ処理がこれらの SQL ステートメントによって定義されたルールに準拠する必要があります。 関連記事:
PHP の一般的な面接の質問

jQuery の一般的な面接の質問

関連動画:

データベース mysql ビデオ チュートリアル

以上が集める！面接で使用される、MySQL 面接の一般的な質問の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。