MySQL のデータベース パフォーマンスに影響を与える要因の説明

データベースのパフォーマンスに関する話

面接では、「データベースにどのくらい精通していますか？」など、データベースに関する話題がある程度議論されます。データベースのパフォーマンスが最もテストされるのはいつですか？一般的には、大量のデータを読み書きするときです。電子商取引の大規模なプロモーション活動は、各データベースのパフォーマンスをテストする時期です。

Web サーバーの場合、データ量が多い場合は、水平方向に拡張するだけで単一サーバーの負荷を軽減できます。しかし、データベース サーバーの場合はそれほど簡単ではありません。水平方向に簡単に拡張できず、データベースの整合性と一貫性の原則にも違反します。では、データベース アーキテクチャはどのように構築すればよいのでしょうか。

大規模なプロモーション活動では、どんなに商品が優れていても、企画が成功していても、安定したデータベースやサーバー環境がなければ、すべて無駄になってしまいます。

データベースアーキテクチャの例

図に示すように、マスターサーバーとスレーブサーバーの間にはマスタースレーブレプリケーションコンポーネントがありません。つまり、マスターサーバーに障害が発生した場合、マスターサーバーを切り替えることは困難です。これにより、DBAはスレーブサーバーから最新のデータを持つスレーブサーバーを選択し、それをマスターサーバーに昇格させ、他のスレーブサーバーを同期する必要があります。このプロセスの時間コストも非常に大きくなります。

さらに、ビジネスボリュームが大きい場合、スレーブ サーバーの数が多すぎると、メイン サーバーのネットワーク カードに一定の負担がかかります。

クラスター監視情報を使用すると、データベースのパフォーマンスに影響を与えるものを把握できます。

答えは「はい」です。一般的に言えば、主な理由は QPS と TPS、同時実行性 (同時接続数との混同を避けるため、同時に処理されるリクエストの数)、ディスク IO、読み取り操作が多すぎることです。

ここで提案があります: メイン データベースのデータをバックアップしないこと、少なくとも大規模なアクティビティの前にそのような計画をキャンセルすることが最善です。

データベースに影響を与える要因

• SQLクエリ速度
• サーバーハードウェア
• ネットワークカードのトラフィック
• ディスクIO

超高QPSとTPS

リスク: 非効率的な SQL (QPS: 1 秒あたりに処理されるクエリ数)

高いCPU使用率と高い同時実行性

リスク: 同時接続数が多い (データベース接続数がいっぱい (max_connections のデフォルトは 100))

リスク: CPU 使用率が非常に高くなる (CPU 枯渇によるダウンタイム)

ディスクIO

リスク: ディスク IO パフォーマンスが突然低下する (より高速なディスク デバイスを使用する)

リスク: ディスクパフォ​​ーマンスを大量に消費するその他のスケジュールされたタスク (スケジュールされたタスクを調整する)

ネットワークカードのトラフィック

リスク: ネットワーク カードの IO がいっぱいです (1000Mb/8=100MB)

データベースに接続できない状況を回避する方法:

1. スレーブサーバーの数を減らす
2. 階層キャッシュを実行する
3. クエリに「select *」を使用しない
4. ビジネスネットワークとサーバーネットワークを分離する