web-dev-qa-db-ja.com

datetime2（0）とdatetime2（2）の比較

ドキュメントによると datetime2（Transact-SQL） ：

ストレージサイズ
精度が3未満の場合は6バイト。
精度3および4の場合は7バイト。
他のすべての精度には8バイトが必要です。

datetime2(0)、datetime2(1)、datetime2(2)のサイズは、同じ量のストレージ（6バイト）を使用します。

datetime2(2)を使用して、サイズのコストを追加せずに精度の利点を得ることができると私は言っても正しいでしょうか？

ご注意ください：

  • この列はPKで索引付けされ、複合クラスター化索引を形成します（テーブルのパーティション化に使用されます）
  • ミリ秒は気にしない

datetime2(0)は、where句で使用する場合、またはインデックスをシークする場合に、CPU効率が向上しますか？

これは巨大なテーブルなので、最小の最適化で大きな違いが生まれます。

sql-serversql-server-2016datetime2
16
Zapnologica

DateTime2（0）、dateTime2（1）、dateTime2（2）、dateTime2（3）のサイズは、同じ量のストレージを使用します。 （6バイト）

DateTime2（3）を使用して、サイズコストを追加することなく精度のメリットを享受することもできますが、私は正しいでしょうか。

いいえ、ドキュメントを誤って解釈しました。ドキュメントの状態ストレージサイズ6バイトの精度以下3（強調鉱山）に注意してください）。したがって、精度が3の場合は7バイトが必要になります。

ミリ秒を気にしない場合は、datetime2(0)が適切なデータ型と精度になります。ベストプラクティスは、保存されたデータに基づいて適切なデータタイプと精度を指定することです。これにより、本質的に最適なストレージと効率が提供されます。そうは言っても、ストレージサイズが同じである限り、指定されたdatetime2精度に基づいてパフォーマンスに大きな影響を与えることはないと思いますが、私自身は特にテストしていません。

ソースでより高い精度を利用できる場合、アプリケーションの要件によって、データベースに何を格納する必要があるかが決まります。たとえば、SYSDATETIME()をソースとする注文入力時間の場合、ユーザーは100ナノ秒の精度を必要としない場合があります。繰り返しになりますが、要件に従って新しい開発のデータ型と精度を選択すると、通常、追加の考慮なしに最適なパフォーマンスが得られます。

上記のように、datetime2は新しい開発に最適ですが、レガシー日時アプリケーションとの互換性のために、代わりに datetime （1/3小数秒精度の固定精度3）を使用する必要がある場合があるため、暗黙的な変換が回避されます。予期しない比較動作ですが、小数秒の精度とストレージの増加を犠牲にしています。

必要以上の精度を保存すると、開発コストもかかる可能性があることを考慮してください。秒の精度のみが必要なときに秒の小数部で時間コンポーネントを保存する場合でも、クエリは小数秒を考慮して正しい結果を返す必要があります。たとえば、ユーザーが秒のみを許可するUIを介して時間範囲を選択するアプリの場合、アプリのコードは、終了時間範囲の値の端数秒を考慮し、それに応じてユーザー指定の値を調整する必要があります（たとえば、 WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'またはWHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'）。これにより、コードが複雑になります。

28
Dan Guzman