Java Road to God：Javaインタビューの準備（15）

6、SpringBootフレームワーク

1.SpringBootとは

SpringBootは元のSpringフレームワークに基づいて簡素化され、ワー​​クロードを削減します

2.SpringBootの利点

1.独立した操作

SpringBootはTomcatなどのさまざまなサーブレットコンテナを埋め込みます。プロジェクトをwarパッケージとしてマークしてコンテナにデプロイする必要はなく、独立して実行するには実行可能なjarパッケージである必要があります。

2.構成を簡素化します

spring-boot-starter-webスターターは自動的に他のコンポーネントに依存し、Maven構成を削減します

3.コード生成およびXML構成なし

SpringBoot構成プロセス中にコードは生成されず、XML構成ファイルを必要とせずにすべての構成タスクを完了することができます。

3.SpringBootのコアアノテーションは何ですか

スタートアップクラスの@SpringBootApplicationアノテーションは、SpringBootのコアアノテーションです。主に以下の3つの注意事項が含まれています

• @SpringBootConfiguration：@COnfigurationアノテーションと組み合わせて、構成ファイルの機能を実現します
• @EnableAutoConfiguration：自動構成機能をオンにするか、特定の自動構成オプションをオフにします
• @ComponentScan：Springコンポーネントのスキャン

4.SpringBootを実行するいくつかの方法

1.mainメソッドを直接実行します

2.jarパッケージとして実行します

3.Mavenプラグインの操作

5.SpringBootでスターターを理解する方法

スターターは、アプリケーションに統合できる一連の依存関係パッケージを含み、Springやその他のテクノロジーをワンストップで統合できるスターターとして理解できます。

セブン、MySqlデータベース

1.データベースの基礎知識

1.1ストアドプロシージャとは何ですか？利点は何ですか？

ストアドプロシージャは、事前にコンパイルされてデータベースに格納されているSQLステートメントのコレクションです。

利点：

1.再利用：再利用できるため、データベース開発者の作業負荷が軽減されます。

2.ネットワークトラフィックの削減：ストアドプロシージャはサーバー上にあり、呼び出し時にストアドプロシージャの名前とパラメーターのみを渡す必要があるため、ネットワークを介して送信されるデータの量が削減されます。

3.セキュリティ：パラメータ化されたストアドプロシージャはSQLインジェクション攻撃を防ぐことができます

短所：

1.ストアドプロシージャは特定のデータベースに合わせてカスタマイズされることがよくあります。サポートされているプログラミング言語が異なるため、他のベンダーからデータベースシステムを切り替える場合は、元のストアドプロシージャを書き直す必要があります。

1.23つのパラダイム

第一正規形：

属性を分割することはできません。各フィールドはアトミックレベルです。たとえば、Studentテーブルでは、ID、名前、クラス番号が1つのフィールドに含まれているとは言えません。

2番目の正規形：

最初のパラダイムを満たすことに基づいて、依存関係の一部が排除されます。非プライマリ属性は、プライマリ属性に完全に依存しています。たとえば、Studentテーブルでは、idとnameが主キーとして使用され、idとname属性は主属性に属し、他のフィールドは非主属性に属します。非プライマリ属性は、IDと名前のいずれかだけでなく、IDと名前の両方に依存する必要があります

第3正規形：

2番目のパラダイムを満たすことに基づいて、推移的な依存を排除​​します。非プライマリ属性は、プライマリ属性に間接的に依存するのではなく、プライマリ属性に直接依存します。

1.3SQLステートメントの実行プロセス

MySQLはクエリ要求を受信すると、最初にクエリキャッシュを調べます。以前に実行されたステートメントとその結果は、キーと値のペアの形式でメモリに直接キャッシュされる場合があります。キーはクエリステートメントであり、値はクエリ結果です。クエリがこのキャッシュ内のキーを直接見つけることができる場合、値はクライアントに直接返されます。

ただし、テーブルの更新操作によってこのテーブルのクエリキャッシュが削除され、Mysql8.0によってクエリキャッシュの部分が削除されるため、一般的なクエリキャッシュのヒット率はそれほど高くありません。

1.4どのようなビュー、ビューの使用シナリオ、および長所と短所

ビューは、1つまたは複数の基本テーブルから派生したテーブルであり、仮想テーブルであるという点で基本テーブルとは異なります。実際のデータはありません。ビューの定義のみがデータベースに保存され、ビューに対応するデータは保存されません。データは元の基本テーブルに残ります。

ビューはウィンドウとして理解できます。ウィンドウを通してデータを表示します。ビューの本質はクエリステートメントです。

ビュー構文を作成する

create view 视图名 as 查询语句

ユースケースを見る

//查询姓张的学生名和专业名
select stuname,mojarname from stuinfo s inner join major m on s.majorid=m.id where s.stuname like '张%';

//创建视图
 create view v1 as select stuname,mojarname from stuinfo s inner join major m on s.majorid=m.id ;
 
//利用视图()
select * from v1 where stuname like='张%';

同じクエリステートメントが複数の場所で使用されており、クエリ構文が非常に複雑な場合は、ビューを使用することをお勧めします

利点

1.ユーザー操作を簡素化する

2.ビューを適切に使用すると、クエリをより明確に表現できます

不利益

1.データベースビューからデータをクエリすると、パフォーマンスが低下する可能性があります

2、ビューはテーブル構造に依存します。テーブル構造が変更されると、ビューも変更されます

1.5mysqlのexlainキーワード

1.5.1 id

クエリシーケンス番号には、繰り返し可能な一連の番号が含まれており、SQLステートメントがmysqlで実行される順序を示します。一般に、次の3つの状況があります。

1. IDはすべて同じで、この場合の実行順序は上から下です。

2. IDが異なります。この場合、MySQLはID番号が大きい方を優先します。

3. IDが同じであるが異なる場合、mysqlは最初にID番号の大きい方を実行し、次にIDの順序に従って上から下に実行します。

1.5.2 select_type

select_typeはクエリのタイプを表し、主に通常のクエリ、共同クエリ、ネストされたクエリを区別するために使用されます。タイプは以下の通りです

• simple：単純なクエリ。これは、クエリ、ネスト、およびその他の操作にサブクエリがないことを意味します。
• プライマリ：クエリにはサブクエリが含まれ、最も外側のクエリはプライマリとしてマークされます
• サブクエリ：サブクエリを表します
• 派生：サブクエリを派生としてマークし、クエリ結果を一時テーブルに保存します
• union：2番目のSELECTがUNIONの後に表示される場合、UNIONとしてマークされます。UNIONがFROM句のサブクエリに含まれている場合、外側のSELECTはDERIVEDとしてマークされます。
• ユニオン結果：ユニオンテーブルから結果を取得します

1.5.3タイプ

タイプ、効果は次のように良いものから悪いものへと分類されます。

system> const> eq_ref> ref> range> index> ALL

1.システム：テーブルにはレコードの行が1つしかありません。これは、constタイプの特殊なケースです。通常は表示されず、無視できます。

2. const：インデックスで1回検出できることを意味し、constは主キーまたは一意のインデックスを比較するために使用されます。1行のデータにしか一致しないため、高速です。主キーがwhereリストに配置されている場合、MySQLはクエリを定数に変換します

3. Eq_ref：一意のインデックススキャン。インデックスキーごとに、テーブル内に一致するデータは1つだけです。主キーまたは一意のインデックススキャンで一般的に使用されます

4. ref：一意でないインデックススキャン、単一の値に一致するすべての行を返します。基本的にはインデックスアクセスです。単一の値に一致するすべての行を返しますが、複数の適格な行が見つかる可能性があるため、混合物に属する必要があります。検索とスキャンの

5.範囲：指定された範囲の行のみを取得し、インデックスを使用して行を選択します。キー列には、使用されているインデックスが表示されます。通常、between、<、>などのクエリはwhereステートメントに表示されます。この範囲スキャンインデックスは、テーブルの特定のポイントから開始するだけでよいため、全表スキャンよりも優れています。 index。、すべてのインデックスをスキャンせずに、別のポイントで終了します

6、インデックス：フルインデックススキャン、インデックスとすべての違いは、インデックスファイルは通常データファイルよりも小さいため、インデックスはインデックスツリーのみを通過することです。これは通常すべてよりも高速です。

7、すべて：全表スキャン、一致する行を見つけるためにテーブル全体をトラバースします

一般的に言えば、クエリが少なくとも範囲レベル、できればrefに到達することを確認する必要があります。

1.5.4possible_key

クエリで使用できるが、実際には使用できないインデックスを示します

1.5.5キー

クエリステートメントで実際に使用されているインデックスを示します。使用されていない場合はnullを示します。

1.5.6 key_len

インデックスで使用されるバイト数を示します。クエリで使用されるインデックスの長さはkey_lenによって計算されます。精度を損なうことなく、インデックスの長さが短いほど良いです。

1.5.7参照

インデックスの値を見つけるために使用されるインデックスの列または定数を示します

1.5.8行

テーブルの統計情報とインデックスの選択に従って、必要なレコードを見つけるために読み取られた行数を概算します。

1.5.9追加

• ファイルソートの使用：mysqlは、テーブル内のインデックスに従って読み取る代わりに、外部インデックスを使用してデータを読み取り、ソートすることを示します。mysqlは、インデックスによって完了したソートを使用してファイルソートになることはできません。
• 一時テーブルの使用：一時テーブルは中間結果を保存するために使用され、mysqlはクエリ結果をソートするときに一時テーブルを使用します
• インデックスの使用：カバーインデックスが使用されていることを示します
• whereの使用：フィルタリングが使用される場所を示します
• 結合バッファの使用：リンクキャッシュが使用されていることを示します

1.6mysqlアーキテクチャ

1.7好きなことなくファジークエリを実行する方法

ファジークエリを実行するときは通常、likeステートメントを使用しますが、likeステートメントのパフォーマンスは少し悪くなります。

select * from user where name like '%张%'

代わりに次の方法を使用できます

1、ステートメントを見つける

select * from user where locate('张',name)>0

2、位置

select * from user where position('张' in name)

3.Instrステートメント

select * from user where instr(name,'张')>0

1.8ページをmysqlに保存する

1.9 页分列

1.10SQLステートメントの最適化

1.テーブルにインデックスを作成し、whereおよびgroupbyで使用されるフィールドを優先します。

2. select *の使用は避けてください。返された役に立たないフィールドは、クエリの効果を減らします。

3.データベースエンジンがインデックスを放棄する原因となるinまたはnotinを使用しないようにしてください

4.またはの使用は避けてください。データベースエンジンがインデックスを破棄する原因になります。

5.フィールドの先頭でファジークエリを使用しないようにしてください。これにより、データベースエンジンが全表スキャンのインデックスを破棄します。

6.データベースエンジンがインデックスを放棄する原因となるnull値の判断を回避するようにしてください

1.11データベースを設計するとき、パラダイムレベルが高いほど良い

答えは間違いなくノーです。

1.12スーパーキー、候補キー、主キー、および外部キーとは何ですか？

• スーパーキー：リレーションシップ内のタプルを一意に識別する属性セットは、リレーションシップモードのスーパーキーと呼ばれます。属性はスーパーキーとして使用でき、複数の属性もスーパーキーとして使用できます。スーパーキーポケモン候補キーと主キー
• 候補キー：最小のスーパーキー、つまり冗長要素のないスーパーキーです
• 主キー：格納されたデータオブジェクトを一意かつ完全に識別するデータベーステーブル内のデータ列または属性の組み合わせ。データ列は主キーを1つだけ持つことができ、主キーの値が欠落したりnullになったりすることはありません
• 外部キー：別のテーブルの主キーが1つのテーブルに存在します。これは、このテーブルの外部キーと呼ばれます。

1.13varchar和char

1.固定長と可変長

charは固定長、固定長を意味し、varcharは固定長を意味します

2.異なるストレージ容量

charの場合、最大255文字を格納できます

varcharは最大65532文字を格納できます

2.Mysqlのインデックス

2.1インデックスとは

• 公式紹介によると、インデックスはMyISAMが効率的にデータを取得するのに役立つデータ構造であり、データベースクエリの速度を上げることができるディレクトリとして理解できます。
• 一般的に、インデックスには、クラスター化インデックス、カバーインデックス、複合インデックスなどが含まれます。MySqlは、インデックスのデータ構造としてB + Treeを使用します
• 一般的に、インデックス自体も非常に大きく、すべてをメモリに保存することは不可能です。そのため、インデックスはディスクに保存されることが多く、個別のインデックスファイルにすることも、データに保存することもできます。データと一緒にファイルします。

インデックスを作成するSQLステートメント

create index index_name on table_name(字段名)

2.2インデックス作成の長所と短所

利点：

• データ取得の効率を改善し、データベースのIOコストを削減できます
• インデックス列でデータを並べ替えると、データの並べ替えのコストが削減され、CPU消費も削減されます

インデックス列は自動的に並べ替えられ、Orderbyステートメントの使用に対応してはるかに高速になります

短所：

• インデックスはディスク領域を占有するため、テーブル内のデータが比較的小さい場合はインデックスを使用しないでください。結局、ディスクの読み取りに時間がかかります。
• インデックスはクエリの効率を向上させますが、テーブルの更新効率を低下させます。テーブルの追加、削除、および変更のためにインデックスを維持する必要があります

​

2.3インデックスの分類

単一列のインデックス

• 通常のインデックス：Mysqlの基本的なインデックスタイプであり、制限はありません。インデックスを定義する列に重複する値とnull値を挿入できます。
• 一意のインデックス：インデックス列の値は一意である必要がありますが、null値は許可されます
• 主キーインデックス：特別な一意のインデックス、null値は許可されていません

複合インデックス

• テーブル内の複数のフィールドの組み合わせで作成されたインデックス
• 複合インデックスの使用は、左端のプレフィックスの原則に従う必要があります
• 通常の状況では、高度なインデックスの代わりに複合インデックスを使用することをお勧めします

2.4インデックスとして使用できるデータ構造は何ですか

2.4.1二分木

2.4.2赤黒木

2.4.3ハッシュテーブル

2.4.4Bツリー

2.4.5 B +ツリー

2.5インデックス作成の基本原則

インデックスは、特定の値を持つレコードをすばやくクエリするために使用されます。インデックスがない場合、通常、クエリの実行時にテーブル全体がトラバースされます。インデックス作成の原則は、順序付けられていないデータを順番に作成することです

1.インデックス付き列の内容を並べ替えます

2.ソート結果の転置リストを生成します

3.反転テーブルのコンテンツにデータアドレスチェーンを配置します

4.クエリを実行するときは、最初に反転テーブルの内容を取得してから、データアドレスチェーンを取り出して、特定のデータを取得します。

2.6インデックスデザインの原則

1.インデックス作成に適した列は、where句に表示される列、またはjoin句の列です。

2.カーディナリティが小さいクラスの場合、インデックス効果は低く、この列にインデックスを作成する必要はありません。

3.短いインデックスを使用します。長い文字列にインデックスを付ける場合は、プレフィックスの長さを指定する必要があります。これにより、インデックススペースを大幅に節約できます。

4.インデックスを使いすぎないでください。インデックスには追加のディスク容量が必要であり、書き込み操作のパフォーマンスが低下します。テーブルを変更するときは、インデックスを維持する必要があります。

2.7インデックス作成の原則

1.左端のプレフィックス一致の原則

2.クエリフィールドとしてより頻繁にインデックスを作成します

3.頻繁に更新されるフィールドは、インデックスの作成には適していません

4.データを効果的に区別できない列の場合、インデックス列には適していません。性別のように

5.インデックスを可能な限り拡張し、新しいインデックスを作成しないでください。

6.外部キーを持つデータ列にはインデックスを付ける必要があります

7.クエリにほとんど関与しない列の場合、重複する値が多い列のインデックスを作成しないでください

8.テキスト、画像、およびビットのデータ型として定義された列のインデックスを作成しないでください

2.8インデックス作成時の注意事項

• 空でないフィールド：列はnull以外として指定する必要があります。mysqlでは、null値を持つ列のクエリを最適化することは困難です。
• 離散値が大きいフィールド：フィールドの繰り返し値が少ない
• インデックスフィールドが小さいほど良いです。フィールドが小さいほど、ストレージページに保存されるインデックスの数が多くなります。

2.9クラスター化インデックス/非クラスター化インデックス/カバーリングインデックス

Innodbの主キーインデックスはクラスター化インデックスであり、MyISamの主キーインデックスは非クラスター化インデックスです。

クラスター化インデックスのリーフノードには、主キー値とデータ行が格納されます

非クラスター化インデックスのリーフノードはインデックスデータを格納し、データ行は別のファイルに個別に格納されます

インデックスカバレッジとは、クエリステートメントの実行をデータテーブルからではなく、インデックスからのみ取得できることを意味します。

2.10インデックスプッシュダウン

• インデックスプッシュダウンは、非主キーインデックスの最適化であり、テーブルに戻る回数を効果的に減らし、クエリの効率を大幅に向上させることができます。

2.11インデックスの失敗

• 左端のプレフィックス原則への違反
• で使用し、で使用しない
• クエリ条件がないか、クエリ条件がインデックスを作成しない
• クエリ条件で先頭の列が使用されていません
• クエリの数は、大きなテーブルの大部分です