一方で、あなたが新しい質問を開いたのは良いことです。しかし一方で、1つのクエリを抽出し、それがより高速に実行されるかどうかを尋ねることによって、前の質問のコンテキストが失われるため、新しい質問はあまりにも孤立しています。ご存知のとおり、データベースの管理、リソース（メモリ/キャッシュ、ディスク、CPUサイクル）の管理、それらのリソースを使用するコード（良好または不良）の管理は、すべて全体像の一部です。パフォーマンスはトレーディングゲームであり、無料のものはありません。
-
私が抱えていた最大の問題は、簡単に導き出せるEndDate列の重複でした。重複する列は、更新の異常と同じです。 Smirkingmanは、古典的な例を提供しています。一部のクエリは1つの結果を取得し、他のクエリは別の結果を取得します。大規模な組織では、それは単に受け入れられません。または、データが監査および保護されている銀行（少なくとも先進国）。基本的な正規化ルールに違反しており、支払われるべきペナルティがあります。
-
Anomailesを更新します。 2つのバージョン（すでに詳細）。監査人はシステムに合格しない可能性があります。
-
テーブルサイズ
大きなテーブルでは問題になります。特に、列の数が少なく、行の数が多い時系列データや時間データでは問題になります。つまり、ディスク容量は安いと言う人もいます。ええ、性感染症もそうです。重要なのは、それが何のために使われるか、そしてどれだけうまくそれを世話するかです。-
ディスク容量
PCでは安価かもしれませんが、実稼働サーバーではそうではありません。基本的に、行サイズ（13 + 8は21に等しい）に62％を追加したため、テーブルサイズになります。私が現在割り当てられている銀行では、データを所有する各部門に次のように課金されます。SANベースのストレージがすべてです。数値は1GBあたり月額です（これはハイエンドのオーストラリアの銀行ではありません）：RAID5ミラーリングされていない場合は1.05ドル
（遅いことはわかっていますが、安価です。重要な情報を入れないでください。壊れた場合は、新しいディスクがホットまたはコールドスワップされた後、数日かかります。自分自身を再同期するためです。）RAID5ミラーリングの場合は2.10ドル
SANでは、つまり。RAID1+0の場合は$4.40
本番データ、バックアップされたトランザクションログ、および夜間のデータベースダンプの最小額。RAID1+0の場合は9.80ドル複製
別の防爆サイトの同一のSANレイアウトに。数分で生産を削減。トランザクション損失はほぼゼロです。 -
メモリ/キャッシュ
わかりました。Oracleにはキャッシュがありませんが、本格的な銀行データベースにはキャッシュがあり、管理されています。特定のキャッシュサイズを指定すると、行の62％のみが同じキャッシュサイズに収まります。 -
論理的および物理的I/O
これは、テーブルを読み取るためのI / Oが50％増えることを意味します。キャッシュへのストリーミングとディスク読み取りの両方。
-
-
-
したがって、クエリのパフォーマンスが単独で良くなるか悪くなるかは、学術的な問題です。上記のコンテキストでは、テーブル は遅く、すべてのアクセスで常に62％パフォーマンスが低下します。そして、それはサーバー上の他のすべてのユーザーに影響を及ぼしています。ほとんどのDBAは、サブクエリフォームが半分の速度で実行されるかどうかを気にしません（私は確かに気にしません）。なぜなら、彼らのボーナスは、コードのパフォーマンスだけでなく、監査の受け入れに関係しているからです。
-
さらに、コードを再訪する必要がなく、更新の異常によるトランザクションを修正する必要がないという追加の利点があります。
-
また、トランザクションには更新するポイントが少ないため、トランザクションは小さくなります。ブロッキングロックなどが少なくなります。
-
-
同意しました、コメントでの議論は難しいです。私の回答では、2つのサブクエリについて詳しく説明しました。誤解がありました：あなたはこのサブクエリについて話していました（WHERE句では、テーブルサブクエリ ）そして私は他のサブクエリについて話していました（列リストでは、スカラーサブクエリ ）私が言ったとき、それは同じくらい速いかもっと速い。これで問題が解決したので、上記の最初のクエリ（WHERE句のサブクエリ、テーブル）が2番目のクエリ（列が重複している）と同じくらい高速に実行されるとは言えません。 1つ目は3回のスキャンを実行する必要があり、2つ目は2回のスキャンのみを実行します。 （ただし、2番目のテーブルスキャンはあえて言います。）
重要なのは、分離の問題に加えて、それは公正な比較ではないということです。私はスカラーサブクエリについてコメントしました。 3スキャンクエリが2スキャンクエリと同じかそれよりも速いことはお勧めしません。
3スキャンテーブルサブクエリ（ここで引用）について私が行ったステートメントは、完全なコンテキスト（totoへの投稿または上記のいずれか）で解釈する必要があります。私はそれから後退していません。
私は人生の半分を、パフォーマンスの問題を前提とした重複した列などの違法な代替案を削除することに費やしています。作成者は、テーブルが遅いというマントラを唱えているため、「パフォーマンスのために非正規化」されています。結果は、開始する前に予測可能で、半分のサイズのテーブルであり、全体の2倍の速度で実行されます。 。時系列はここで最も一般的な質問です（リンクは別の質問にリンクしています。別の質問にリンクしています）が、銀行データベースの問題を想像してみてください：毎日の
OpeningExposureおよびClosingExposureSecurityごとHoldingごとUnitTrustごとPortfolioごと 。 -
しかし、まだ聞かれていない質問に答えさせてください。この種の相互作用は正常であり、社内の開発チームと協力する場合は珍しくありません。少なくとも月に1回は発生します。クラッシュホットな開発者は、重複した列を持つテーブルを使用してコードを作成してテストしましたが、飛んでしまいましたが、データベースに配置しないため、現在は停止しています。
いいえ、システム全体のコンテキスト内でテストします および：
-
半分の時間、1秒で実行される0.5秒のクエリについて大したことはないため、テーブルはEndDate列なしで入ります。
-
残りの半分の時間、[テーブルサブクエリ]のパフォーマンスは許容できないため、
IsCurrentを識別するためのブール（ビット）インジケーターを実装します。 。これは、複製された列よりもはるかに優れており、2スキャン速度を提供します。 -
百万年も経たないうちに、私にコラムを複製してもらうことはできません。テーブルサイズに62％を追加します。 完全なマルチユーザーコンテキストでテーブルの速度を落とす 62％;監査に失敗するリスクがあります。そして、私は従業員ではありません。ボーナスはもらえません。
これでテストする価値があります：重複した列を使用したクエリと
IsCurrentを使用したクエリ 全体的なリソース使用の完全なコンテキストでのインジケーター。 -
-
Smirkingmanは良い点を挙げています。そして、それが断片化されて、いずれかの断片が攻撃されないように、明確に言い換えます。これを分割しないでください：
リレーショナルデータベース。
経験豊富なリレーショナルモデラーによって正規化され、真の5番目の正規形になります
（更新の異常なし、重複する列なし）、
完全なリレーショナルコンプライアンスを使用
（IDEF1X、特にIdの最小化に関連 主キー;したがって、リレーショナルエンジンの能力を損なうことはありません）
結果として、テーブルが小さくなり、データベースが小さくなり、
インデックスが少なくなり、
必要な結合が少なくなります
（そうです、テーブルは多くなりますが、結合は少なくなります）、
そして、同じハードウェア上でこれらのルールのいずれかに違反するものよりも優れたパフォーマンスを発揮し、エンタープライズ dbプラットフォーム
（フリーウェア、MS、Oracleを除く。ただし、それで止めないでください）、
本番OLTPの完全なコンテキストでは
少なくとも1桁使用し、
使用と変更がはるかに簡単になります。
（「リファクタリング」は必要ありません）。私はこれを少なくとも80回行いました。他の誰かがそれを行うためのフレームワークを提供するのではなく、私が自分でそれを行う場合、2桁は珍しいことではありません。
一緒に仕事をしている人やお金を払っている人ではなく、私も1つのクエリが単独で何をするかを気にしません。