私が読んだSQLコードはたくさんありますが、開発者は既定の並べ替え順序が常に成立すると想定しているようです。たとえば、HTML選択リストを作成するときには、SELECT id, name FROM tableのORDER BY句を発行しないでください。デフォルトの並べ替え順序を処理するSQLのベストプラクティス
私自身の経験からは、ORDER BY節が与えられていない場合はインデックスを持たない場合、dbmsはFIFOを使用してデータを並べ替えるようです。ただし、その順序は保証されていません。しかし、テーブルに変更がなければ、dbmsによるデータの並べ替えは見たことがありません。
テーブルに変更がない場合、dbmsが非決定的な順序でデータを選択したことはありますか？
常にORDER BY句を入れるのがベストプラクティスですか？
デフォルトのソート順はありません。表にクラスタード・インデックスがある場合でも、その順序で結果を取得することは保証されません。特定の注文が必要な場合は、order by句を使用する必要があります。
あなたが最初だったのは、最初は –
でした。 – Yada
データが一貫して注文されるようにするには、はい - ORDER BYを使用する必要があります。
はい。 ORDER BYのない「デフォルト注文」はありません。FIFO/LIFOまたは他の注文でデータを戻すという保証はありません。限り、「テーブルからID、名前を選択し、」使用する開発者は、彼らは無能のどちらかだか、彼らが何をして表示される注文何を気にしないよう
。
重大なRDBMSはあなたない限り、任意の順序を保証します明示的なORDER BYを指定します。
他にも純粋な運やanectodalだけがあります。注文をしたい場合は、ORDER BYを指定する必要があります。
おそらく、読んでいるSQLクエリの作者は、返されるデータの順序は気にしません。ベストプラクティスは、返される結果の順序を保証する必要がある場合に使用することです。
データを整列させるには、何かを保証する唯一の方法（私が認識しているすべての主要なRDBMSシステム、確かにSql ServerとOracle）はORDER BY句を含めることです。 FIFOはORDER BY句なしでデータが返される順序とはまったく関係なく、DEFAULTソート順の概念はありません。いわゆるDEFAULTソート順は、基本的にエンジンがデータを取得します。これは、インデックス、キャッシュデータ、同時実行クエリ、サーバへの負荷などに基づいて文字どおりである可能性があります。
This other stackoverflow thread基本的にSql Serverと同じ概念をカバーするAlexK blogged a repoを使用して、動作を示します。
SELECT ... FROM tableのような単純なクエリでも、さまざまな順序でデータを返すことができます。理論的には真実であると私は知っていますが、これは実際には真実であることが分かります。テーブルにデータの変更がない場合でも、後続の実行間で順序が変わるケースはたくさんあります。
実行間の順序変更の典型的な例は、クエリが並列プランを使用して実行される場合です。並列演算子は基礎となるスレッドが生成するデータを返すので、結果の行の順番は実行ごとに異なります。この状況では、たとえ単純なSELECTであっても、毎回異なる結果が返されます。
他のポスターで言及しているように、ソート順を指定しない場合、SQL標準によれば、結果は問合せプロセッサが最も効率的かつ効率的な方法で検索できます。
インデックスがなくプライマリキーがないCUSTOMERテーブルのすべての行に対して単純な順序付けられていないSELECTを実行するとします。クエリプロセッサがストレートテーブルスキャンを実行し、最初に挿入された順序で行を生成する可能性があります（見たFIFO動作を与える）。
STATEフィールドとCITYフィールドにインデックスを順番に追加してからWHERE STATE = 'NY'をクエリすると、クエリプロセッサは、実行するのではなくSTATE = 'NY'のインデックスエントリをスキャンする方が効率的だと判断することがありますフルテーブルスキャン。この場合、おそらくSTATE、CITYの順で行がマテリアライズされます。
これは確かではありません。たとえば、クエリプロセッサが統計情報を収集してテーブルのほぼすべてのSTATE値が 'NY'（おそらくデータベースがAlbanyベースの機器レンタルビジネス用であるため）であることを示す統計情報を収集すると、テーブルスキャンが実際に安価であると判断することがありますインデックススキャンよりも、FIFOが再び表示されます。
データベースがクエリを計画する方法についていくつかの基本を学ぶことをお勧めします。 EXPLAINステートメントを使用して、DBMSがどのようなクエリを実行するかを確認し、これを使用してクエリを最適化することもできます。これは魅力的で有用な学習領域です。
、どこ動的なレコードセットをなど「クライアント側」グリッド型コントロールに表示されているので、私は、SQLで BY ORDERを指定していないほとんどの時間並べ替えがサポートされています - この場合、SQLによる並べ替えはで、不要なのはです。とにかくクライアント側でチェックされます。
これはクライアント側でも行われます。これは、同じクエリを使用して、異なる順序で異なる場所にデータを表示することができるためです。
したがって、データの順序が重要な場合
つまり、フロントエンドの開発者がそれを「並べ替え」する場合、処理時間全体を節約することはできないため、ポイントはありません。
これは、独自のソート対象となるクライアント側がある場合には、良い点です。もちろん、すべてのクエリがクライアントアプリケーションに送信されているわけではなく、いくつかの場合はエクスポートファイルを作成しているので、ordierngは非常に重要です。しかし、最も効率的なものを実行することは良いことです。クライアント側で再ソートする場合は、ソートしないほうが効率的かもしれません。しかし、私は両方の方法をテストします。 – HLGEM
私が行ったように誰かがこれを使いたい場合に備えて、私はこれを書いています。
私は満足できるデフォルトの並べ替え順序を得ています。ログテーブルについては、インデックスの並べ替えを使用します。たとえば、私は通常、ログテーブルの最後の行（LIFO）に興味があるので、DateTime DESCを順序として作成します。私はまた、プライマリキーの横にある他のフィールド（整数）にインデックスを追加するのも面白かったです。
CREATE TABLE [dbo].[tableA]([DateTime] [datetime] NOT NULL,
CONSTRAINT [PK_tableA]
PRIMARY KEY CLUSTERED ([DateTime] DESC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY]
またはSSMSで...
SQL準拠のデータベースには、定義上、*デフォルトのソート順*はありません。ほとんどのデータベースは、クエリの性質や類似したクエリが実行された時点のインデックスの状態によっても、異なる順序でレコードを返すことができます。順序が重要であると仮定して、必ずデータを格納する順序を指定する必要があります。指定されていない順序のクエリは繰り返し実行できないことがあります。 –