回答。

複数のソートは、データを複数の列（たとえば、最初に日付、その後名前、さらに合計金額）でランク付けまたはグループ化する必要があるレポートを作成する際に最も重要なツールです。従来、ソートは厳密に1つのフィールドによってのみ行われており、データの総合的な分析の課題を解決するものではありませんでした。

問題は、しばしば誤ったソート順序（たとえば、NULL値が予期しない場所に現れる）、コレーションのエラー（異なる言語の文字列値に対するソートルール）、および大きなデータセットにおけるパフォーマンスの低下にあります。

解決策: マルチカラムORDER BYを使用し、COLLATIONの特性を考慮し、結果の決定性を保証するためにNULLSの順序を明示的に定義し、大きなテーブルでは列のインデックスを確認することです。

コード例:

SELECT * FROM sales
ORDER BY region COLLATE "ru_RU", date DESC NULLS LAST, total_amount DESC;

主な特徴:

データ型全体にわたって複数の列をソートできます。
NULLの位置をNULLS FIRST/LASTを通じて明示的に管理します。
文字列列に対してCOLLATEを明示的に設定できます（サポートはDBMSによります）。

サブ問題。

COLLATEを指定しない場合、異なるサーバーで常に同じソート結果になりますか？

いいえ！デフォルトのCOLLATEはデータベースやサーバーの設定に依存し、文字列のソート結果（特にキリル文字や特殊文字を含む）はインストールによって異なる場合があります。

DESCおよびASCでのソート中にNULLはどこに配置されますか？

SQLの標準ではこれを明確に定義していません。一部のDBMSでは、ASCでNULLが上に配置され、他のDBMSでは下に配置されます。NULLS FIRSTまたはNULLS LASTを明示的に指定して、動作が明確になるようにしてください。

ORDER BY price DESC NULLS LAST

複数の列でのORDER BYがインデックスの使用に影響を与えますか？

はい、ただし順序、型、および列の値のクリーンさが既存の複合インデックスに一致する場合のみです。順序が混在している（ASC/DESC）場合や計算列が使用されている場合、インデックスは使用されない可能性があります。

一般的なエラーとアンチパターン

COLLATEを指定しないことで、開発者はサーバーの異なる言語設定で異なる結果を得ます。
レポート内のNULLに対する暗黙的なソートは、選択された異なる部分に空の行が予期しない形で出現します。
インデックスのない/計算されたフィールドに対する巨大なORDER BYは、リソースを無駄に消費します—ソートするフィールドを最初にインデックス化してください。

実生活の例

ネガティブケース

マネージャーがCOLLATEなしで姓によるORDER BYを含むレポートを作成しました。異なるサーバー間でレポートを移動すると、ロシア語とラテン語の姓が入れ替わり、NULLは時々上部、時々下部にありました。

メリット:

コードが最小。 デメリット:
予測不可能な動作とサポートの困難。

ポジティブケース

レポートにはCOLLATEとNULLの順序をNULLS FIRST/LASTで明示的に指定し、ソートフィールドに複合インデックスを追加しました。動作は環境に依存しなくなり、クエリの速度が大幅に向上しました。