ドキュメントdatetime2（Transact-SQL）によると：
ストレージサイズは
、精度が3未満の場合は6バイトです。
精度3および4の
場合は7バイトです。他のすべての精度には8バイトが必要です。
大きさはdatetime2(0)、datetime2(1)、datetime2(2)ストレージの同量（6バイト）を使用します。
datetime2(2)サイズコストを追加せずに精度の利点を享受することもできると言って正しいでしょうか？
ご注意ください：
うdatetime2(0)where句で使用された場合、より多くのCPU効率的であること、またはインデックスを通じて追求するとき？
これは巨大なテーブルなので、最小の最適化で大きな違いが生じます。
回答:
dateTime2（0）、dateTime2（1）、dateTime2（2）、dateTime2（3）のサイズは、同じ量のストレージを使用します。（6バイト）
dateTime2（3）を使用して、追加のサイズコストなしで精度の利点を得ることができると言って正しいでしょうか。
いいえ、ドキュメントを誤って解釈しました。文書には、精度が 3 未満の場合のストレージサイズが6バイトであることに注意してください（強調は私のものです）。したがって、3に等しい精度には7バイトが必要です。
ミリ秒を気にしない場合はdatetime2(0)、適切なデータ型と精度になります。ベストプラクティスは、保存されたデータに基づいて適切なデータタイプと精度を指定することです。これにより、本質的に最適なストレージと効率が提供されます。そうは言っても、ストレージサイズが同じである限り、指定されたdatetime2の精度に基づくパフォーマンスへの大きな影響は期待できませんが、私は特にテストしていません。
ソースでより高い精度が利用できる場合、アプリケーションの要件により、データベースに何を保存する必要があるかが決まります。たとえば、からソースされた注文入力時間のSYSDATETIME()場合、ユーザーは100ナノ秒の精度を望んでいない場合があります。繰り返しになりますが、要件に応じて新規開発用のデータ型と精度を選択すると、通常、追加の考慮なしに最適なパフォーマンスが得られます。
上記のようにdatetime2は新しい開発に最も適していますが、レガシーdatetimeアプリケーションとの互換性のために、datetime（1/300の小数秒精度の固定精度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'）。これにより、コードが複雑になります。
smalldatetimeSELECT CAST(GETDATE() AS smalldatetime);