2024 Java インタビュー --mysql(3)

シリーズ記事の目次

1. 2024 Java インタビュー (1) – 春の章
2. 2024 Java インタビュー (2) – 春の章
3. 2024 Java インタビュー (3) – 春の章
4. 2024 Java インタビュー (4) – 春の章
5. 2024 Java インタビュー – コレクション
6. 2024 年の Java インタビュー – redis(1)
7. 2024 年の Java インタビュー – redis(2)

---

---

mysqlの最適化

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

インデックスはデータベース クエリを高速化するための鍵です。テーブル構造を設計するときは、クエリ要件に基づいて適切なインデックスを追加する必要があります。一般的に使用されるインデックスには、主キー、一意のインデックス、通常のインデックス、結合インデックス、プレフィックス インデックス (vachar や text などの長いデータの場合、高度な差別化を実現するには最初のいくつかのみが必要です) などが含まれます。

同時に、各インデックスには記憶領域が必要であり、書き込みパフォーマンスに影響を与えるため、インデックスが多すぎることは避けてください。

2. クエリの最適化

クエリ ステートメントの最適化は、MySQL のパフォーマンスを向上させる重要な手段です。可能な限りインデックスを使用し、テーブル全体のスキャンを避けてください。同時に、サブクエリの使用を避け、可能な限り結合クエリを使用すること、クエリでのワイルドカード文字「%」の使用を避けること、冗長なフィールドなどを避けることなどです。

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

合理的なテーブル構造により、クエリの効率が向上し、ストレージ領域が削減されます。TEXT、BLOB などの大きなフィールドは、多くの記憶領域を占有するため、避けてください。同時に、更新やメンテナンス中の複雑さを避けるために、冗長なフィールドは避ける必要があります。

①1つのデータベースは200テーブルを超えてはいけません

②1つのテーブルのデータ数が500万件を超えないこと

③1つのテーブルは40列を超えてはいけません

④単一テーブルインデックスは5つまで

4. キャッシュの最適化

キャッシュを使用すると、MySQL データベースへの負荷が大幅に軽減され、クエリ効率が向上します。一般的に使用されるキャッシュ テクノロジには、Memcached や Redis などがあります。

5.パーティションの最適化

大量のデータを含むテーブルの場合、パーティショニング テクノロジを使用してテーブルを複数の部分に分割できます。これにより、クエリの効率が向上し、単一テーブルの記憶領域とインデックス サイズが削減されます。

6. 構成の最適化

MySQL パラメータの設定は MySQL のパフォーマンスに影響します。バッファ、接続数、スレッド数、クエリキャッシュなど、実際の状況に応じて調整する必要があります。

7. ハードウェアの最適化

ハードウェア デバイスも MySQL のパフォーマンスに影響を与える可能性があります。より高速なディスク、より高速な CPU、より多くのメモリなど、より高速なハードウェア デバイスを選択します。同時に、RAID、SSD、その他のテクノロジーを使用するかどうかは、実際の状況に基づいて決定する必要があります。

DQL 構文

論理ストレージ構造

1. データを挿入する

#客户端连接服务端时，加上参数--local-infile
​
mysql --local-infile -u root-p
​
#设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
​
set global local_infile = 1;
​
#执行load指令将准备好的数据，加载到表结构中
​
load data local infile '/root/sql1.loginto table tb_user fields terminated by ',' lines terminated by '\n';
​
主键顺序插入性能高于乱序插入

2. 主キーの最適化

ビジネス ニーズを満たす場合は、主キーの長さをできる限り短くするようにしてください。

データを挿入するときは、順次挿入するようにし、AUTO_INCREMENT を使用して主キーを自動インクリメントしてください。

UUID を主キーまたは ID 番号などの他の自然主キーとして使用しないようにしてください。

業務運用中は、主キーの変更を避けてください。

3. 最適化による順序付け

1. filesort を使用すると、テーブル インデックスまたはフル テーブル スキャンを通じて条件を満たすデータ行が読み取られ、ソート バッファーでのソート操作が完了します。インデックスによるソート結果を直接返さないすべてのソートは、FileSot ソートと呼ばれます。
2. インデックスを使用する場合: 順序付きインデックス順次スキャンにより、順序付けされたデータが直接返されます。この場合、インデックスを使用すると追加のソートが必要なく、操作効率が高くなります。

#没有创建索引时，根据age, phone进行排序
explain select id,age,phone from tb_user order by age , phone;
#创建索引
create index idx_user_age_phone_aa on tb_user(age,phone);
#创建索引后，根据age, phone进行升序排序
explain select id,age,phone from tb_user order by age , phone;
#创建索引后，根据age, phone进行降序排序
explain select id,age,phone from tb_user order by age desc , phone desc ;
#根据age, phone进行降序一个升序，一个降序
explain select id,age,phone from tb_user order by age asc , phone desc;
#创建索引
create index idx_user_age _phone_ad on tb_user(age asc ,phone desc);
#根据age, phone进行降序一个升序，一个降序
explain select id,age,phone from tb_user order by age asc , phone desc;

並べ替えフィールドに基づいて適切なインデックスを確立します。複数のフィールドで並べ替える場合、左端のプレフィックス ルールにも従います。

カバー インデックスを使用してみてください (クエリ対象のフィールドは、テーブルを返すクエリを実行する必要がなく、ジョイント インデックスで直接クエリできます)。

昇順と降順の複数フィールドのソート このとき、結合インデックス (ASC/DESC) を作成するときの規則に注意する必要があります。

ファイルソートが避けられない場合は、大量のデータをソートするときにソートバッファーサイズ sort_buffer_size (デフォルトは 256k) を適切に増やすことができます。

4. 最適化によるグループ化

インデックスを使用すると、グループ化操作の効率を向上させることができます。

グループ化操作を実行する場合、インデックスの使用は左端のプレフィックス ルールも満たします。

#执行分组操作，根据profession字段分组
explain select profession , count(*) from tb_user group by profession;
#创建索引
Create index idx_user_pro_age_sta on tb_user(profession , age , status);
#执行分组操作，根据profession字段分组
explain select profession , count(*) from tb_user group by profession;
#执行分组操作，根据profession字段分组
explain select profession , count(*) from tb_user group by profession,age;

5. 制限の最適化

よくある非常に厄介な問題は、制限 2000000,10 です。現時点では、MySQL は最初の 2000010 レコードをソートする必要があり、2000000 ～ 2000010 レコードのみを返します。他のレコードは破棄され、クエリ ソートのコストが非常に高くなります。

最適化のアイデア: 一般的なページング クエリを実行する場合、カバー インデックスを作成することでパフォーマンスを向上させることができます。カバー インデックスとサブクエリを追加することで最適化できます。

explain select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) a where t.id = aid;

6. カウントの最適化

count のいくつかの使用法

count (主キー) : InnoDB エンジンはテーブル全体を走査し、各行の主キー ID 値を取り出し、それをサービス層に返します。サービス層は主キーを取得した後、それを行ごとに直接蓄積します (主キーを null にすることはできません)。

count (field) : not null 制約はありません: InnoDB エンジンはテーブル全体を走査し、各行のフィールド値を取り出してサービス層に返します。サービス層は null かどうかを判断しますか否かでカウントが累積されます。

not null 制約があります。InnoDB エンジンはテーブル全体を走査し、各行のフィールド値を取り出し、サービス層に返し、行ごとに直接蓄積します。

count (1) : InnoDB エンジンはテーブル全体を走査しますが、値は取得しません。サービス層は返された各行に数値「1」を入れ、それを行ごとに直接累積します。

count (*) : InnoDB エンジンはすべてのフィールドを取得するわけではありませんが、値を取得せずにフィールドを最適化します。サービス層は行を直接カウントします。

効率に従ってソートすると、 count (フィールド) count (主キー ID) < count (1) ≈ count (*) となるため、 count () を使用してみてください。

MyISAM エンジンはディスク上のテーブルの総行数を保存するため、count(*) を実行するとこの数値を直接返します。これは非常に効率的です。

InnoDB エンジンに問題が発生しているため、count(*) を実行する際には、エンジンからデータを 1 行ずつ読み取り、カウントを蓄積する必要があります。

7. アップデートの最適化

InnoDB の行ロックはレコードではなくインデックスのロックであり、インデックスは失敗することができません。失敗すると、行ロックからテーブル ロックにアップグレードされます。

更新プロセス中の where 条件がインデックスがないことである場合、行ロックはテーブル ロックにアップグレードされます。

where 条件にインデックスが付けられている場合は、通常の行ロックになります。