phpデータベースの基本

トランザクション

トランザクションの 4 つの特性 (ACID):

原子性、一貫性、分離性、耐久性
- (1) 原子性
トランザクション全体において 必要な操作はすべて正常に送信されるか、すべて失敗してロールバックされる必要があります。
- (2) 整合性
操作前後のデータベース内のデータの整合性を確保します。 (例: ユーザーの複数のアカウント間で送金するが、ユーザーの合計金額は変更されません)
- (3) 分離
分離では、送信が完了する前に、データベース内のデータを変更するトランザクションが必要です。見えない。 (つまり、トランザクションはシリアルに実行する必要があります)

SQL 標準では 4 種類の分離が定義されています: (以下の分離は低から高、同時実行性は高から低の順です)

1) 最も低い分離コミットされていない読み取りレベルにより、他のトランザクションがコミットされていないデータを参照できるようになり、ダーティ リードが発生します。

2) Read Committed
データベースは読み取りと書き込みが分離されているため、トランザクションの読み取り時に読み取りロックが取得されますが、読み取り後すぐに解放されます。読み取りロックが解放された後は、他のトランザクションによってデータが変更される可能性があります。再度読み取ると、前後のデータの読み取り結果が異なることが判明し、繰り返し読み取りができなくなります。 (読み取りロックはトランザクションの送信後に解放する必要はありませんが、書き込みロックはトランザクションの送信後に解放する必要があります)

3) 反復可能な読み取り
一貫性のない読み取りを避けるため、select によって取得されたすべてのデータは変更できません取引の前後。ただし、現時点では他のトランザクションは選択されたデータを変更できませんが、データを追加できるため、ファントム読み取りを制御する方法はありません。

4) シリアル化可能
すべてのトランザクションは順番に実行されるため、ファントム読み取りは回避できます。ロックベース 同時実行制御を実装しているデータベースの場合、シリアル化では範囲クエリの実行時に範囲ロックを取得する必要があります。データベースがロックに基づく同時実行制御を実装していない場合、シリアル操作に違反するトランザクションが検出された場合、トランザクションは範囲ロックを取得する必要があります。事態が巻き戻されること。

概要: 4 つのレベルは段階的に強化されており、トランザクション レベルが高くなるほど、ほとんどの環境でパフォーマンスが低下します (read commit は使用可能)

分離レベル ダーティ リード Non-repeatable read Phantom。 read
まだ Read uncommitted (read uncommitted) 可能
Read commited (read commit) 不可能 可能
Repeatable read 不可能 不可能 Serializable (直列化可能) 不可能

概要: コミットされていない読み取りはダーティ 読み取りの原因になります -> コミットされた読み取りはダーティ 読み取りを解決します。反復不可能な読み取りが発生します -> 反復可能な読み取りにより、一貫性のない読み取り結果の問題が解決されますが、ファントム読み取りが発生します (以前はありませんでしたが、現在は) -> 大量の範囲ロックを追加すると、ロック タイムアウトが発生する可能性があります。 ;

(4) 永続性 トランザクションがコミットされると、その変更はデータベースに永続的に保存されます。この時点でシステムがクラッシュしても、送信された変更データは失われません。

ダーティ リード、非反復読み取り、およびファントム リード

(1) ダーティ リード (ロールバック操作の場合): トランザクション T1 はレコードの行の内容を更新しましたが、トランザクション T2 が更新行を読み取った後、変更をコミットしませんでした。 、その後、T1 はロールバック操作を実行し、直前に加えた変更をキャンセルします。 T2 によって読み取られた行の数は無効です (1 つのトランザクションが別のトランザクションを読み取ります)

(2) 反復不可能な読み取り (変更された操作の場合): トランザクション T1 がレコードの行を読み取り、次に T2 が T1 のレコードの行を変更します。読み取った後、T1 はこのレコード行を再度読み取り、その結果が今読み取った結果と異なることがわかります。

(3) ファントム読み取り (更新操作の場合): トランザクション T1 は、指定された where 句によって返された結果セットを読み取り、その後、トランザクション T2 がレコードの新しい行を挿入します。これは、たまたま T1 によって使用されたクエリ条件を満たします。次に、T1 はテーブルを再度取得しますが、T2 によって挿入されたデータが再度表示されます。 (最初は見ませんでしたが、2回目で見ました)

インデックス

2.1 データベースインデックスの長所と短所は何ですか?また、データベースインデックスが失敗するのはどのような場合ですか?

インデックスの特徴

(1) はデータベースの検索を高速化できます;

(2) はビューではなくテーブルにのみ作成できます
(4) ) インデックスを使用できます。最適化の非表示で;
(5) クエリ プロセッサを使用してテーブルで SQL ステートメントを実行できるのは、一度に 1 つのインデックスだけです。

インデックスの利点

(1) データベース テーブル内のデータの各行の一意性を確保するために、一意のインデックスを作成します。
(2) インデックスを作成する主な理由であるデータの取得を大幅に高速化します。データベース テーブル間の転送 リンクは、データベースの参照整合性を達成する上で特に意味があります。
(4) 検索にグループ化および並べ替え句を使用する場合、クエリでのグループ化と並べ替えの時間も大幅に短縮できます。インデックスは、クエリで最適化ハイダーを使用してシステムのパフォーマンスを向上させることができます。

インデックスの欠点

(1) インデックスの作成と維持に時間がかかり、数が増えると時間がかかります。

(2) インデックスは物理的なスペースを占有する必要があります。データテーブルが占有するデータスペースに加えて、各インデックスは一定量の物理スペースも占有します。

(3) テーブル内のデータを比較する場合。削除や変更を行うと、インデックスも維持する必要があるため、データのメンテナンス速度が低下します。

インデックス分類

(1) 通常のインデックス (制限はありません。)

(2) 固有のインデックス (インデックス列は一意である必要がありますが、null 値も許可されます）

(3) 主キーインデックス (null 値を許可しない特殊な一意のインデックス。通常、主キーインデックスはテーブルの作成時に同時に作成されます) .)
(4) 複合インデックス
(5) クラスター化インデックスは、各テーブルの主キーに従って B+ ツリーを構築し、テーブル全体の行レコード データがリーフ ノードに格納されるため、クラスター化インデックスもデータ ページになります。
(6) 非クラスター化インデックス (補助インデックス) (ページ ノードはレコードの行全体を保存しません)。

インデックスが無効です

(1) 条件に or がある場合、条件にインデックスがあっても使用されません (or をできるだけ使用しません)

(2) like クエリは % で始まります。例: SELECT * FROM mytable WHEREt Name like'%admin';

(3) 列の型が文字列の場合、条件内で引用符で囲む必要があります。そうでない場合、インデックスは使用されません

インデックス: (コアは B ツリー インデックスを理解します)

Myisam、InnoDB、Memonry の 3 つの一般的に使用される MySQL エンジン タイプは

B と比較されます。 -ツリーインデックスはサポートをサポートします
R-Tree インデックスのサポートはサポートしていません 全文インデックス 未サポート 未サポート 未サポート

データベース内のインデックス構造？どのような状況でインデックスを作成するのが適切ですか?

データベース内のインデックス構造?
バイナリ ツリーを使用する場合、バイナリ ツリーの深さが大きすぎるため、I/O の読み取りと書き込みが頻繁になり、クエリ効率が低下するためです。したがって、マルチウェイ ツリー構造を使用すると、B ツリーに対するさまざまな操作によって B ツリーの高さを低く抑えることができます。

B ツリーはバランス型マルチパス検索ツリーとも呼ばれます。m 次の B ツリーの特徴は次のとおりです。

- 1. ツリー内の各ノードには最大 m 個の子が含まれます (m>=2)。 - 2. ルート ノードを削除します。リーフ ノードを除き、他のすべてのノードには少なくとも (ceil (m/2)) 個の子があります (ceil (x) は上限を取る関数です)。 3. ルート ノード。少なくとも 2 つの子を持ちます (B ツリーに 1 つのノード (ルート ノード) のみが含まれている場合を除きます)。 4. すべての葉ノードは同じレベルに表示され、葉ノードにはキーワード情報が含まれません (外部ノードと見なすことができます)。 (注: リーフ ノードには子と子へのポインタがないだけです。これらのノードも存在し、要素を持ちます。赤黒のツリーに似ています) 、各 null ポインターはノードとみなされ、描画されないだけです)

どのような状況でインデックスを構築するのが適していますか? (1) は頻繁に表示されるフィールドです。キーワード order by、group by、distinct の後にインデックスを作成します。

(2) Union およびその他の集合演算の結果セット フィールドにインデックスを作成します。インデックスを作成する目的は上記と同じです。クエリの選択によく使用されるフィールドのインデックスを作成します。

(4) 頻繁に使用されるテーブル リンクの属性にインデックスを作成します。
(5) ユーザーがデータをほとんど更新しないテーブルの場合は、インデックス カバレッジの使用を検討します。多くの場合、いくつかのフィールドのみをクエリするため、これらのフィールドにインデックスを構築することを検討してください。したがって、テーブルのスキャンをインデックスのスキャンに変更します。

Mysql 構文の順序

つまり、次のキーワードが SQL に存在する場合、この順序を維持する必要があります:
select[distinct]、from、join (left join など)、on、where、group by、having、union、 order by,limit;

Mysql の実行順序

つまり、実行時、SQL は次の順序で実行されます:
from、on、join、where、group by、having、select、distinct、union、order by
group by to 集約関数で使用します。例:
select a.Customer,sum(a.OrderPrice) fromorders a where a.Customer='Bush' or a.Customer = 'Adams' group by a.Customer
implement multi-テーブルクエリ (内部結合)
select u.uname,a.addr from lm_user u inner join lm_addr a on u.uid = a.uid
select from where を使用することもできます
select u.uname,a.addr from lm_user u, lm_addr a where u.uid = a.uid;

ストアド プロシージャ

delimiter

createprocedureprocedurebill()comment'Query all sales'beginselectbillid,txtime,amtfromlmbill;end

delimiter; process_bill() ;
ストアド プロシージャを表示する
'procedure_bill' のようなプロシージャ ステータスを表示する

MySQL データベースで多対多のデー​​タ テーブル関係を確立する

データベース内で 2 つのテーブル間の関係が多対多である場合- 対多の関係: 「学生テーブルとコーススケジュール」。データベースの設計原則に従って、1 人の学生が複数のコースを選択でき、1 つのコースを複数の学生が選択することもできます。3 番目の関連付けテーブルが必要です。形成されました。

ステップ 1: Student、Course、Stu_Cour の 3 つのデータ テーブルを作成します

/**学生表*/CREATE TABLE Student (
stu_id INT AUTO_INCREMENT,
NAME VARCHAR(30),
age INT ,
class VARCHAR(50),
address VARCHAR(100),PRIMARY KEY(stu_id)
)
/*学生课程表*/CREATE TABLE Course(
cour_id INT AUTO_INCREMENT,
NAME VARCHAR(50),
CODE VARCHAR(30),PRIMARY KEY(cour_id)
)
/**学生课程关联表*/CREATE TABLE Stu_Cour(
sc_id INT AUTO_INCREMENT,
stu_id INT ,
cour_id INT,PRIMARY KEY(sc_id)
)

ステップ 2: Stu_Cour 関連テーブルに外部キーを追加します

/*添加外键约束*/
ALTER TABLE Stu_Cour ADD CONSTRAINT stu_FK1 FOREIGN KEY(stu_id) REFERENCES Student(stu_id);
ALTER TABLE Stu_Cour ADD CONSTRAINT cour_FK2 FOREIGN KEY(cour_id) REFERENCES Course(cour_id);

作成が完了しました。

注: すでに追加されているデータ テーブルに外部キーを追加します。

-構文: alter table table name addconstraint FK_ID 外部キー (外部キー フィールド名) REFERENCES 外部テーブル名 (対応するテーブルの主キー フィールド名) 例: alter table tb_active add constraint FK_ID external key(user_id) REFERENCES tb_user(id);

SQL 最適化

NO SQL データベース

よく使用されるデータベースは何ですか? Redisを使ったことがありますか?

一般的に使用されるリレーショナル データベース:

Mysql、SQLServer、Oracle

一般的に使用されるスキーマレス データベース:
MongoDB、Merncached、Redis...
Redis
(1) Redis は、キー (キー) と 5 種類の値 (値) を組み合わせて、メモリに保存されたキーと値のペアのデータをハードディスクに永続化できます。
(2) Merncached との比較
1) どちらもキーと値のマッピングの保存に使用でき、パフォーマンスはほぼ同じです。
2) redis は 2 つの異なる方法でハードディスクにデータを自動的に書き込むことができます。通常の文字列キーの保存に加えて、他の 4 つのデータ構造も保存できます。
4) Redis は、他のストレージ システムのメイン データベースと補助データベースの両方として使用できます。ストレージエンジン)

エンジンとは何ですか?
データベースにアクセスするときは、手動アクセスでもプログラム アクセスでも、データベース ファイルを直接読み書きするのではなく、データベース エンジンを通じてデータベース ファイルにアクセスします。

リレーショナル データベースを例に挙げると、SQL ステートメントをデータベース エンジンに送信すると、データベース エンジンが SQL ステートメントを解釈し、必要なデータを抽出して返します。したがって、訪問者にとって、データベース エンジンは SQL ステートメントのインタープリターです。

MYISAM エンジンと InnoDB エンジンの違い

主な違い:
- (1) MYISAM は非トランザクションセーフですが、InnoDB はトランザクションセーフです。
- (2) NYISAM ロックの粒度はテーブルレベルのロックですが、InnoDB は行レベルのロックをサポートします。 (3) MYISAM はフルテキスト インデックスをサポートしますが、InnoDB はフルテキスト インデックスをサポートしません
- (4) MYISAM は比較的シンプルなので、効率の点で InnoDB よりも優れています
- (5) MYISAM テーブルはファイルとして保存されます。クロスプラットフォーム データ転送で MYISAM ストレージを使用すると、多くのトラブルが軽減されます。
- (6) InnoDB テーブルは MYISAM テーブルよりも安全であり、非トランザクション テーブルは損失することなくトランザクション テーブルに切り替えることができます。データ;
アプリケーション シナリオ:
- (1) MYISAM は、アプリケーションが多数の選択クエリを実行する必要がある場合に、高速なストレージと取得、および全文検索機能を提供します。 MYISAM の方が良い選択です。
- (2) InnoDB はトランザクション処理アプリケーションに使用され、ACID トランザクションのサポートを含む多くの機能を備えています。アプリケーションで大量の挿入または更新操作を実行する必要がある場合は、マルチユーザーの同時操作のパフォーマンスを向上させることができる innodb を使用する必要があります。

その他

データベースのパラダイムとは何ですか

現在リレーショナルデータベースには6つのパラダイムがあります：第一正規形{1NF}、第二正規形{2NF}、第三正規形{3NF}、バス・コッド正規形{BCNF } }、第 4 正規形 {4NF}、第 5 正規形 {5NF、完全正規形とも呼ばれます}。最小要件を満たすパラダイムは、第 1 正規形です。第 1 正規形に基づいて、さらに標準的な要件を満たすものを第 2 正規形 {2NF} と呼び、他のパラダイムもこれに準じます。一般に、データベースは第 3 正規形 (3NF) を満たすだけで済みます。 。

標準:

(1) 1NF: 各列がアトミックのままであることを確認します。

(2) 2NF: テーブル内の各列が主キー (結合主キー) に関連付けられていることを確認します。 Each 列が主キー (外部キー) に直接関連付けられていることを確認します

(4) BCNF: 1NF に基づいて、非主属性は主キーのサブセットに依存できません (3NF に基づいて、主キーのサブセットへの依存は排除されます);

(5)4NF: 同じテーブル内の多対多の関係を削除する要求

(6)5NF: 最終的な構造から元の構造を再構築します。