トランザクション
トランザクションの 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 (直列化可能) 不可能
(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 ツリーの高さを低く抑えることができます。
- 1. ツリー内の各ノードには最大 m 個の子が含まれます (m>=2)。 - 2. ルート ノードを削除します。リーフ ノードを除き、他のすべてのノードには少なくとも (ceil (m/2)) 個の子があります (ceil (x) は上限を取る関数です)。 3. ルート ノード。少なくとも 2 つの子を持ちます (B ツリーに 1 つのノード (ルート ノード) のみが含まれている場合を除きます)。 4. すべての葉ノードは同じレベルに表示され、葉ノードにはキーワード情報が含まれません (外部ノードと見なすことができます)。 (注: リーフ ノードには子と子へのポインタがないだけです。これらのノードも存在し、要素を持ちます。赤黒のツリーに似ています) 、各 null ポインターはノードとみなされ、描画されないだけです) 
どのような状況でインデックスを構築するのが適していますか? 
(1) は頻繁に表示されるフィールドです。キーワード order by、group by、distinct の後にインデックスを作成します。
(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) )
/*添加外键约束*/ 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 は、他のストレージ システムのメイン データベースと補助データベースの両方として使用できます。ストレージエンジン)
エンジンとは何ですか?
データベースにアクセスするときは、手動アクセスでもプログラム アクセスでも、データベース ファイルを直接読み書きするのではなく、データベース エンジンを通じてデータベース ファイルにアクセスします。
主な違い:
- (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 を使用する必要があります。
標準:
(5)4NF: 同じテーブル内の多対多の関係を削除する要求 (6)5NF: 最終的な構造から元の構造を再構築します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
