データの冗長性とマルチテーブルクエリを選択
最近自宅で退屈し、共同でデータ処理、クエリとリンクテーブルのデータ冗長運転でのMySQLの最適化問題でのパフォーマンスを経験して、ブログサイトの開発に小さなパートナーのフロントエンドは、それが選択する方法である必要があり、これが伴うだろうデータベースとカウンターパラダイムパラダイム
問題の説明
ブログの記事のコメントを取得する場合、この時間は、マルチテーブルクエリを有効にするか、それはデータの冗長性を使用するかどうか、いくつかは直接、それがかもしれテーブルクエリを結ぶ、それについて考えることがあるので、レビューのニックネームとアバター画像のリンクを取得する必要があります一部の人々は、時間のために、データの冗長性、スペースを言います
分析
私たちは、この問題が発生したときしかし、私たちは中に発生する可能性が他の問題を考える必要があります
私たちはこのような状況に遭遇したとき、私は今、コメント、データの冗長性の方法を使用すると、まず、望ましくないときに私たちも、テーブル、クエリのパフォーマンスを分析
# 建表语句
CREATE TABLE `comment` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`article_id` int(11) NOT NULL,
`detail` varchar(100) NOT NULL,
`publish_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `article_user_id` (`article_id`,`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8
マルチテーブルクエリの分析から、我々は、主キーのクエリに基づいており、インデックス、クエリ、（ユーザ情報）2番目のクエリを使用して、最初のクエリを渡す（および記事のコメントを取得する）見ることができます。実際には、このマルチテーブルクエリ、パフォーマンスは本当に弱いではありません
データの冗長性
我々はデータを使用している場合は重複し、各レビュアーのコメントのニックネームとアバターリンクの背面に保存されている私たちは、クエリ時に、そう、あなたは、2番目のクエリのための時間を節約することができますが、これも、スペースの無駄が生じない最も重要な彼らのあらゆるニーズコメントからコメントを取得し、内部テーブルを変更するときは、ニックネームまたはユーザー名を変更した場合、想像ので、非常に低いパフォーマンス。
だから、データの冗長性を使用しますとき
関連するデータはほとんど変化しないとデータの量とき、あなたはプロ、分割表の学生のように、データの冗長性を使用することができる場合、クエリの言葉、毎回学生情報フォームと関連する専門的な情報テーブルが、私たちは単に、ビッグデータの大規模な量は、それがパフォーマンスの低下の原因となりますクエリとテーブルに行かなければならない、学生とその専門的な時間を照会今回の場合、学生に時間的にデータの冗長性、冗長な情報の専門的名称の使用、大幅に改善されたクエリのパフォーマンスと引き換えに、小さなスペースを犠牲に
