データベースの概要_08

GUIクライアント

SQLyog は、MySQL データベースを管理するためのグラフィカル ツールです。どこにいてもデータベースを管理できます。ネットワーク経由でリモートの MySQL データベースを維持できます。DBA に適しています。

Navicat for MySQL は、開発者向けの強力な MySQL データベース管理および開発ツールです。

リモートサービスを有効にする

デフォルトでは、MySQL はリモート ログイン サポートを有効にせず、ローカルホストでのみ使用できます。

まずローカルホスト上のデータベースにログインします。

mysql -uroot -p123456

use mysql; -- 切换当前系统库
update user set host='%' where user='root';

認可を使用して付与を処理することもできます

alter user 'root'@'localhost' identified with mysql_native_password by '123456'

接続プロセス中に暗号化プラグインの認証に失敗したことが報告された場合は、パスワードに使用される暗号化方式を変更できます。新しい機能 caching_sha2_password が MySQL8 で導入されました。クライアントは通常、暗号化方式 mysql_native_password をサポートします。

索引

インデックスは、ストレージ エンジンがレコードを迅速に検索するために使用するデータ構造です。これには追加のスペースとデータ メンテナンス作業が必要です。

物理ストレージ方式による: クラスタリングと非クラスタリング

MyISAM: frm メタデータ ファイル、myd データ、sdi インデックス データ、MyISAM は非クラスター化
インデックス、データとインデックスは別々に保存されます
InnoDB: ibd メタデータ ファイル、データとインデックス、innodb ストレージ エンジンはクラスター化インデックスをサポートします

データ構造によると: B+ ツリー、ハッシュなど。

論理的に: 主キー インデックス、共通インデックス、一意のインデックス、空間インデックス (空間データ用)、およびフルテキスト インデックス

B ツリー

B ツリーは自己平衡型マルチフォーク探索木であり、最大 m (m>=2) 個のフォークを開くことができ、m 次 B ツリーと呼ばれます。

• リーフ以外のノードには最大でも m 個の息子があると定義します。
• ルート ノードは m-1 個のキー値を持つことができます [特定のデータ キー値がノードに格納されます]、ルート ノードの子の数は [2,m] です
• ルートノードを除く非リーフノードの息子の数は[m/2,m]であり、非リーフノードのキーワードの数は息子の数-1である。
• すべてのリーフ ノードは同じレベルにあります
• k 個のキーワードを使用してノードを k+1 個のセグメントに分割し、それぞれ k+1 個の息子を指しますが、同時に検索ツリーのサイズ関係を満たす必要があります。

B ツリーの特徴:

• キーワードのコレクションはツリー全体に分散されます
• 任意のキーワードが表示され、1 つのノードにのみ表示されます
• 検索は非リーフ ノードで直接終了する可能性があり、その検索パフォーマンスはキーワードの完全なセットにおける二分検索 O(logN) と同等です。
• 
  B ツリーはデータの挿入および削除時に B ツリーの性質を破壊するため、データの挿入および削除時にB ツリーの性質を維持するためにデータの分割、マージ、転送などの操作が必要です。

B+ ツリー

Bツリーをベースにシーケンシャルアクセスポインタを追加するものです

• n 個のサブツリーを持つノードには n 個のキーが含まれます
• すべてのキーワードはリーフ ノードに格納され、リーフ ノードはキーワードの小さい順から大きい順に接続されます。
• 非リーフ ノードはインデックス部分と見なすことができ、ノードにはサブツリー内の最大または最小のキーのみが含まれます。

B+ ツリーの検索プロセスは B ツリーと似ていますが、検索時に非葉ノードのキーが指定された値と等しい場合、検索は終了せず、引き続き葉ノードの位置を指し続ける点が異なります。ポインター。したがって、B+ ツリーでの検索が成功したかどうかに関係なく、各検索はルートからリーフまでの完全なパスをたどります。

B+ツリーの特徴:

• すべてのキーワードはリーフ ノードに保存され、リンク リスト内のキーワードはたまたま順序どおりになっています。
• 非リーフノードヒットになることはあり得ず、すべてのクエリの実行時間は安定しています
• 非リーフノードはリーフノードのインデックスに相当し、リーフノードはデータを格納するストレージ層に相当します。
• ファイルインデックスシステムに最適

B-treeを導入する理由

赤黒ツリーもインデックス作成を実装できますが、ファイル システムとデータベース システムでは通常、B ツリーまたは B+ ツリーが使用されます。

まず、インデックスを作成する必要があるデータの規模が比較的大きいため、インデックスによって発生するデータ量が少なくなりすぎず、すべてをメモリに格納することは不可能です。ファイルの形式でディスクに保存されるため、インデックス検索プロセスではディスク IO を消費する必要があります。インデックスの組織構造では、検索プロセス中のディスク IO アクセスの数を最小限に抑える必要があります。

ディスクの読み取りは厳密にはオンデマンドではなく、毎回先読みされます。これは局所性の原則に基づいており、データの一部が使用されると、通常は近くのデータも使用されます。ディスクの逐次読み取り効率は非常に高く、局所性の原理に従って、先読みメカニズムにより IO 効率が向上します。先読みの長さは通常、コンピュータのストレージ管理用の論理ブロックであるページの整数倍で、ページ サイズは通常 4k または 8k です。

データベースでは、ディスクの事前読み取りの原理を使用して、ノードのサイズをページのサイズに設定します。各ノードは 1 つの IO だけで完全にロードできるため、B ツリーを次のように使用すると非常に効率的です。インデックス構造。赤黒ツリーを使用する場合、ツリーの高さは B ツリーの高さよりもはるかに高く、B ツリーの高さは通常 3 ～ 4 層にすぎません。

mysqlインデックス

インデックスとは、実際にはキーワードとデータの間のマッピング関係であり、キーワードはデータを識別して検索するためにデータから抽出される特定の内容です。

• キーワードはデータに比べてデータ量がはるかに少ない
• キーワードは順序どおりに並べる必要があり、二分検索で場所をすばやく特定できます。

MySQL のインデックス タイプは、通常のインデックス、一意のインデックス、主キー インデックス、フルテキスト インデックス、空間インデックス (空間タイプのデータの場合) に分類できます。

• 通常のインデックス: キーワードの制限なし
• 一意のインデックス: キーワードが重複を許可しないという制約を実装するために使用されます。
• 主キーインデックス: 主キーは一意である必要があり、空にすることはできません。

基本的なコマンド

show create table テーブル名;
desc テーブル名;

インデックスを作成する

インデックスを作成するには 2 つの方法があります。

• 主キーや一意性制約など、テーブル作成時に対応するインデックスを作成します。

create table tb_users(
	id bigint auto_increment, -- 实际会有报错
	first_name varchar(16),
	last_name varchar(16),
	id_card varchar(18),
	memo text,
	primary key(id), -- 主键索引
	key name1(first_name,last_name),
	unique key(id_card),
	fulltext key(memo)
);

• テーブル作成後にインデックスを作成する

create table tb_users(
	id int auto_increment primary key, -- 建立了主键索引
	username varchar(20) unique, -- 建立唯一性索引
	memo text
);

alter table tb_users drop column username;
alter table tb_users add first_name varchar(16);
alter table tb_users add last_name varchar(16);

//一个列可以构成索引，索引也可以是由多个列构成
-- 建立一个复合索引，并且命名为name1
alter table tb_users add key name1(first_name,last_name);

-- 创建全文索引,具体存储采用倒排索引的方式，不支持中文分词。如果业务需要使用搜索引擎，建议使用ES实现全文搜索
alter table tb_users add fulltext(memo);

インデックスの削除

通常のインデックス、一意のインデックス、全文インデックスに対応し、インデックス名に従って削除操作を実行できます。

構文: alter table テーブル名 drop key インデックス名

alter table tb_users drop key name1; -- 删除名称为name1的复合索引
alter table tb_users drop key id_card; -- 删除名称为id_card的唯一性索引
alter table tb_users drop key memo;

主キー インデックスを削除します: alter table table namedrop Primary key。テーブルには主キーが 1 つしか持てず、主キーは複数の列で構成できるため、ここにはインデックス名はありません。主キーが自然に大きくなった場合、直接削除することはできないことに注意してください。auto_increment は主キーインデックスに依存する必要があるため

削除する必要がある場合は、まず自己拡張をキャンセルしてから、主キー インデックスを削除する必要があります。

alter table tb_users modify id bigint;
alter table tb_users drop primary key;

実際、主キーには自然主キーと代理主キーの2種類があるため、特定の開発では主キーを削除することはほとんどありませんが、ビジネスルールとは関係のない代理主キーを使用することをお勧めします。

実行計画

SQL ステートメントを実行するときは、最初に分析と最適化を行って実行計画を作成し、最後に実行計画に従って操作を実行して、結果セットを操作します。Explain を使用すると、SQL の実行前に実行計画を分析できます。

create table tb_users(
	id bigint primary key auto_increment,
	username varchar(20) unique,
	city varchar(10),
	province varchar(10),
	key name1 (province,city)
);

insert into tb_users values(null,'zhangsan','西安','陕西');

クエリ操作の実行計画を表示する

explain select * from tb_users where id<10;

• id クエリ操作の一意の識別子
• select_type はクエリのタイプを表示します
• 表には、このクエリに関連するテーブルが表示されます
• パーティション クエリ一致パーティション
• type は使用されるアクセス テーブルのタイプを示します。ALL フル テーブル クエリ、インデックスはインデックス ツリーを使用、範囲指定の範囲クエリ
• possible_keys クエリ時に使用される可能性のあるインデックス
• キーで使用されるインデックス
• key_len インデックスフィールドの長さ
• ref インデクス列等価クエリを使用する場合、インデクス列と等価一致するためのオブジェクト情報
• rows スキャンされた行数
• filtered テーブル条件に従ってフィルタリングされた行の割合
• エクストラ実行ステータスの説明と説明

ビューの実行プランを使用して、定義されたインデックスが特定のクエリのクエリ効率を最適化できるかどうかを判断できます。

alter table tb_users add sex char(1) default '男';
explain select * from tb_users where sex='男';

これは、インデックスが有効ではなく、テーブル全体がクエリ データをスキャンすることを意味します。

インデックスの使用シナリオ

1.頻繁に検索が必要な列および主キー列の場合

explain select * from tb_users where id>1

id クエリ レコードによると、主キー インデックスは id 列に作成されるため、SQL ステートメントによって実行されるオプションのインデックス pos​​sible_keys には主キー インデックスのみが含まれます。複数の異なるインデックスがある場合は、より適切なインデックスが選択されます。検索の基礎となります。

2. ソートまたは範囲クエリ条件による順序の列

並べ替えによる順序の操作を実行するときに、フィールドにインデックスが作成されていない場合、実行プランはクエリされたすべてのデータに対して外部並べ替えを使用します。操作はパフォーマンスに影響します。alter table 表名称 add index(列名称)インデックスを作成するために使用できますが、インデックス自体に順序が付けられているため、インデックスの順序に従ってデータを 1 つずつ直接読み取ることができます。ページング操作も伴う場合は、すべてのデータを取得するのではなく、インデックス テーブル内の特定の範囲のインデックスに対応するデータのみを取得します。

特定の開発では、クエリをページ分割する必要があります

• 論理ページングでは、最初にすべてのデータをメモリにロードし、次に表示用のデータの一部を取得します。
• 物理ページングとは、クエリ時に必要な明示的なデータのみが取得され、表示されないデータはロードされないことを意味します。select * fromtb_users limit 起始行号，每页行数

3. 接続クエリ結合を実行する必要がある

結合ステートメントの一致関係に関係するフィールドにインデックスを付けると、結合クエリの実行効率が向上します。

インデックスカバレッジ

クエリ対象のフィールドがすべてインデックス付けされている場合、ストレージ エンジンは元のデータにアクセスせずにインデックス テーブルに対して直接クエリを実行します。これはインデックス カバレッジと呼ばれます。したがって、インデックスカバレッジの確率を高めるために、必要なクエリフィールドを可能な限り選択後に記述する必要があります。

• 注: 最初にインデックスを使用すると、インデックスのサイズが小さくなるという利点があるため、各フィールドにインデックスを作成しないでください。
• インデックスは追加の記憶域スペースを必要とするだけでなく、データの追加、削除、変更のパフォーマンスにも影響を与えるため、通常はテーブルに対して 6 つ以下のインデックスを作成することをお勧めします。

インデックスの失敗

where、order by、join...on、インデックスカバレッジなどの用途を満たす場合、必ずしもインデックスを使用する必要はありません
1、フィールドは独立して出現する必要があります

select * from tb_users where id=20-1; 
-- 会使用主键索引

select * from tb_users where id+1=20; 
-- 不会使用主键索引,针对列使用了表达式计算或者函数

2. いいねクエリ

select * from tb_users where name like '%方%'; 
-- 由于使用%统配符开头，所以在name上创建的索引无效，只能进行全表扫描，
-- 效率极低，实际开发中不建议使用；如果使用较为频繁建议引入第三方的
-- 全文索引来实现

select * from tb_users where name like '方%'; 
-- name上创建的索引是有效

3. 複合インデックスは左側のフィールドに対して有効である必要があり、左端のプレフィックス一致原則が必要です。

alter table tb_users add index(first_name,last_name);

具体的な実装原則は、最初に first_name から抽出されたキーワードに従ってソートし、順序が決定できない場合は last_name から抽出されたキーに従ってソートすることです。インデックス複合インデックスが有効になるための前提条件は、左側の列がクエリに参加します

select * from tb_users where first_name=’zhangsan‘; -- 可以使用索引
select * from tb_users where first_name='zhang' and last_name='san'; -- 索引生效
select * from tb_users where last_name="lisi"; -- 无法利用索引

クエリ条件に関してはfirst_name=? and last_name=?、first_name と last_name の複合インデックスを作成する方が、first_name インデックスと last_name インデックスをそれぞれ作成するよりも効率が高くなります。

4. または条件付きクエリ

インデックスが有効になるのは、or の両側にインデックスがあり、片側で SQL ステートメント全体のフル テーブル スキャンが行われていない場合です。

5. 状態値にインデックスを付ける必要はありません

性別や注文ステータス フィールドなどの値を取得できる可能性は少なくなります。このようなフィールドにインデックスが作成されても、ステータス値は多数のレコードと一致する可能性があるため、多くの場合利用できません。この場合、mysqlフルテーブルスキャンの効率が低いため、インデックスは破棄されます。

インデックスの作成方法

インデックス作成は、クエリ効率の向上と引き換えにスペースを無駄にします。インデックス作成は変更操作のパフォーマンスに影響を与える可能性があります

1. 基本的なインデックスの構築: where、order by、join フィールドのインデックスを構築します。

2. 複合インデックスの最適化: ビジネス ルールとビジネス ロジックに基づく

• 条件が頻繁に同時に出現する場合は、複数のフィールドのインデックスを複合インデックスにアップグレードすることを検討してください。
• 個々のフィールドのインデックスを追加すると、インデックス カバレッジが発生する可能性があります。このフィールドのインデックスを構築することを検討してください。

3. クエリ内に頻繁に出現しないインデックスを削除する必要がある場合

4. インデックス作成後の SQL ステートメントの使用に注意する

• % の先頭にあるファジー クエリによりインデックスが失敗します。
• インデックス列は空ではないことが望ましく、インデックスには null 値が表示されません。性別ブール値のデフォルト 1
• not in または != クエリを少なく使用します。not in は notexists に置き換えることができます。
• 列に対して計算を実行しないでください。列に対して提案されたインデックスが無効です。

5. Explain を使用して実行計画を表示し、インデックスが有効かどうかを判断します。

プレフィックスインデックス

一般に、インデックス テーブルは特定のデータ テーブルよりも小さいことが望まれます。インデックスを構築する場合、デフォルトではフィールドの内容全体がインデックスの構築に使用されます。フィールドの内容全体ではなく、フィールドの最初の 10 文字を使用してインデックスを構築するように指定できます。文法： index(列名称(长度))

プレフィックスインデックスを使用する前提は、フィールドのプレフィックス識別度が比較的高いことです。たとえば、各パスワードはほとんど異なるため、パスワードはプレフィックスインデックスの作成に適しています。

プレフィックス インデックスを使用する場合の難しさは、プレフィックス インターセプトの長さをどのように定義するかということです。

lenの値を調整することで、異なるプレフィックスの平均一致度を確認できselect count(*)/count(distinct left(password,len)) 、1 に近い値であれば問題ありません。

インデックスの具体的な実装

Innodb ストレージ エンジンはインデックス構成テーブルを使用しており、Innodb ではテーブル データ ファイル自体が B+ ツリーに従って編成されたインデックス構造です。MyISAM のプライマリ インデックスと補助インデックスの間に構造的な違いはありません。ただし、プライマリ インデックスには一意のキー値が必要ですが、補助インデックスのキー値には重複が許可されている点が異なります。

Innodb ストレージ エンジン

innodb のデータ ファイルは主キー [クラスター化インデックス] に従って集約および保存されるため、innodb のデータ テーブルには主キーが必要ですが、MyISAM には主キーがありません。主キーが明示的に指定されていない場合、mysql は識別可能な列を主キーとして自動的に選択します。識別可能な列がない場合、mysql は innodb テーブルの暗黙的なフィールドを主キーとして自動的に生成します。このフィールドは 6B です

補助インデックスは、まず補助インデックス テーブルを取得して対応する主キーを取得し、次に主キーを使用してメイン インデックス テーブルから対応するデータを取得します。

Innodb では、すべての補助インデックスで主インデックスを使用する必要があるため、長すぎるフィールドを主キーとして使用することはお勧めできません。主インデックスが長すぎると、補助インデックスが大きくなります。整数データを次のように使用することをお勧めします。主キー。占有スペースが少なく、比較的高速です。さらに、非単調フィールドを主キーとして使用することは得策ではありません。innodb データ ファイル自体は B+ ツリーであり、非単調主キーにより、維持するためにデータ ファイル内で頻繁な分割調整が発生するためです。新しいレコードを挿入するときの B+ ツリーの特性。効果は非常に低いです。ベスト プラクティス: bigintauto_increment のサロゲート主キーの使用を検討してください。

MyISAMストレージエンジン

MyISAM メイン インデックスはインデックス構造として B+ ツリーを使用し、リーフ ノードのデータ フィールドにはデータ レコードのアドレスが格納されます。

MyISAM 補助インデックスも B+ ツリーであり、データ レコードのアドレスはデータ フィールドに保存されます。

MyISAMインデックスの検索アルゴリズムは、まずB+ツリーの検索アルゴリズムに従って対応するキーを検索し、キーが存在する場合はデータフィールドに格納されているアドレス値を取得し、最後に対応する行のデータを取得します。このリーフノードには特定のデータは格納されません データの格納方法は非クラスター化インデックスと呼ばれます

ハッシュインデックス

インデックスがメモリにロードされた後、ハッシュ構造を使用してデータを保存します

HashMapの実装と同様

Innodb のロック機構

データベースの使用目的はデータ共有であり、データへの同時アクセスを考慮する必要があります。解決策はロック機構です

ロックには主にグローバル ロック、テーブル ロック、行ロック、楽観的ロック、悲観的ロックが含まれます。

ストレージエンジン

ストレージ エンジンは、MySQL 内のデータ、インデックス、その他のデータベース オブジェクトの保存方法を定義し、ファイル システムの実装です。

面接の初期の質問: MyISAM と Innodb をどのように選択しますか?
MySQL の Innodb ストレージ エンジンは完璧ではなく、基本的にあらゆる面で MyISAM に追いつきつつあり、MySQL のデフォルト エンジンでもあるため、この問題は基本的に現在は存在しません。 MySQL。

すべてのストレージ エンジンを表示するshow engines;

一般的なストレージ エンジン: MyISAM、Innodb、メモリ

• MyISAM はフル テーブル ロックを使用しており、クエリの実行速度が高く、トランザクションと外部キーをサポートしておらず、同時実行パフォーマンスは劣っていますが、占有スペースは比較的小さく、トランザクションの要件はありません。アプリケーションはこのエンジンを使用できます
• Innodb は行レベルのロックを使用しており、コミット、ロールバック、および回復機能によるトランザクション セキュリティを提供し、自己成長クラスをサポートし、外部キー制約をサポートし、強力な同時実行パフォーマンスを備えています。一般に、必要なスペースは MyISAM の 2.5 倍以上です比較的効率が低い
• メモリはフルテーブルロックを採用しており、メモリ上にデータを格納するので高速ですが、データ量に比例してメモリ空間を占有するため、MySQLの再起動時にデータが失われます。検索効率の高いデフォルトのハッシュインデックスが使用されます。 、ただし、範囲検索には適していません。主に、内容があまり変更されないテーブルをキャッシュするために使用されます。
• アーカイブ このタイプのテーブルは挿入、選択のみをサポートし、削除、更新、置換はサポートせず、インデックスを使用しません。
• csv これらのテーブルはサーバー上の 1 つのファイルに保存され、カンマで区切られたデータが含まれます。

Innodb と MyISAM の違い

• Innodb はトランザクションをサポートしていますが、MyISAM はサポートしていません。Innodb はデフォルトで各 SQL ステートメントをトランザクションとしてカプセル化し、自動的に送信するため、実行速度に影響します。
• Innodb は外部キー制約をサポートしますが、MyISAM はサポートしません。そのため、外部キーを含む innodb テーブルの場合、MyISAM への変換は失敗します。
• Innodb がクラスター化インデックスを採用する場合、データ ファイルとインデックスはバインドされており、主キーが必要であり、主キーによるクエリ効率は非常に高いですが、補助インデックスは 2 回クエリする必要があるため、主キーはInnodb ではキーが大きすぎてはなりません。MyISAM は非クラスター化インデックスを使用するため、データ ファイルは分離されます。
• InnoDB はデータの総行数を保存せず、select count( ) の実行にはテーブル全体のスキャンが必要ですが、MyISAM は変数を使用してテーブルの総行数を保存するため、count() クエリの実行はとても速いです
• Innodb5.5- はフルテキスト インデックス作成をサポートしていませんが、MyISAM はフルテキスト インデックス作成をサポートしており、MyISAM の方がクエリ効率が高いです

次の方法で選択してください:

• 特別な要件がない場合は、デフォルトの innodb を使用します。
• MyISAM: ブログ システム、ニュース Web サイトなど、読み取りと挿入に重点を置いたアプリケーション。検索エンジンにはNoSQL型データベースESを採用し、
• Innodb: 更新および削除の操作には高い効率性またはデータの整合性の確保が必要であり、OA などの管理システムなど、同時実行性の要件が高いシナリオの使用を検討してください。トランザクションと外部キーをサポートしているため、データの整合性を非常によく保証できます。

	マイＩＳＡＭ	Innodb
トランザクションサポート	サポートしません	サポート
ロックの粒度	サポートテーブルロック	サポートされている行ロック

Innodb ストレージ エンジンは行レベルのロックとテーブルレベルのロックの両方をサポートしており、デフォルトでは行レベルのロックが使用されます。ロック タイプには、共有 S ロック、排他的 X ロック、インテント共有 IS ロック、およびインテント IX 排他的ロックが含まれます。

いわゆるインテント ロックとは、インテント ロックがノードに追加されると、そのノードの下位層のノードが束縛されることを意味します。任意のノードにロックを追加する場合、その上位層にインテント ロックを追加する必要があります。初め。

ロックの目的は、テーブル ロックが行レベルのロックがあるかどうかをすぐに認識できるようにして、テーブル ロックが行ロックの実行を妨げないようにすることです。

ロックモード	Xロック	IXロック	Sロック	ISロック
Xロック	対立	対立	対立	対立
IXロック	対立	互換性	対立	互換性
Sロック	対立	対立	互換性	互換性
ISロック	対立	互換性	互換性	互換性

テーブルロック

ロックの粒度はテーブル全体です
lock tables 表名称 read/write 。読み取りは共有ロックで、一度ロックされると読み取りデータは共有され、書き込みは排他ロックで、ロックされたクライアントのみが読み取りと書き込みが可能で、他のクライアントは読み取りと書き込みができません。

ロックを解除するunlock tables

行レベルのロック

ロックの粒度はテーブル内の特定の行です。

共有ロックselect * from 表名称 where 条件 lock in share mode;

排他ロックselect * from 表名称 where 条件 for update;

注: いわゆる行ロックは、特定の行のデータを直接ロックするのではなく、実際にはサブ範囲をロックするため、ギャップ ロックとも呼ばれます。たとえば、実際
select * from tb_student where id<20 lock in share mode には id<20 の既存データをロックしているのではなく、id<20 の範囲をロックしています。たとえば、id 18 の新しいレコードを挿入すると失敗します。

デッドロックの問題

デッドロックとは、2 つ以上のトランザクションが同じリソースを占有し、お互いのリソースのロックを要求し、悪循環が発生する現象です。

デッドロックを解決する一般的な方法

• 異なるプログラムが複数のテーブルに同時にアクセスする場合は、同じ順序でテーブルにアクセスすることに同意するようにしてください。これにより、デッドロックの可能性を大幅に減らすことができます。
• 同じトランザクション内で、デッドロックの可能性を減らすために、必要なすべてのリソースを一度にロックするようにしてください。
• デッドロックが発生しやすいビジネス部分の場合は、アップグレードされたロック粒度を使用して、テーブル レベルのロックを通じてデッドロックの可能性を減らすことができます。

業務処理がうまくいかない場合は、分散トランザクションロックまたは楽観的ロックを使用できます。

• tb_users を更新し、salary=? を設定します。ここでID=1
• update tb_users set給与=?,version=2 where id=1 and version=1 [version は、現在の行のバージョン番号を記録するために使用される追加の列です]

クエリキャッシュ

メモリを浪費して高い実行効率を得る代わりに、select ステートメントのクエリ結果をキャッシュできます。

• このダウンロード版は起動できない問題が発生する可能性があります。テストには他のバージョンを使用してください。

構成パラメータ query_cache_type

• 0 開いていません
• 1 キャッシュを有効にすると、すべての選択がデフォルトでキャッシュされます。キャッシュしない必要がある場合は、選択ステートメントに sql-no-cache を追加して、キャッシュを破棄するように求めるプロンプトを表示する必要があります。
• 2 キャッシュを有効にします。デフォルトではキャッシュなし。SQL ステートメントに select sql-cache active caching を追加する必要があります。

mysql 設定ファイル、Windows では my.ini、Linux では my.conf を追加する必要があります

query_cache_type=1

MySQL キャッシュが有効になっているかどうかを確認する

show variables like 'query_cache_type';

オープンクエリのキャッシュサイズを構成する

set global query_cache_size=64*1024*1024; -- 配置查询缓存为64M

show variables like 'query%';

クエリ結果を

select sql_cache * from tb_users where ...;

キャッシュをリセットする

reset query cache;

アプリケーションの問題

1. アプリケーションはクエリ キャッシュの使用を気にする必要はありません。クエリ キャッシュの使用にはデータベースの構成情報を変更する必要があるため、実際には DBA によって決定されます。

2. SQL文をキーとしてキャッシュが格納されるため、同じ機能のSQL文であっても、スペースが余っていたり、大文字小文字が異なる場合、キャッシュされたデータは一致しません。