特定のアプリでは、最後に挿入された行にある可能性が高いデータを常にクエリする必要があります。このテーブルは非常に大きくなるため、テーブルの最後でルックアップを開始するようにクエリを最適化する標準的な方法があるのではないかと思います。データベースがテーブルのデータをスタックのような構造で保存した場合、同じ最適化が得られると思います。そのため、最後に挿入された行が最初に検索されます。
10 に答える
4
SQL 仕様では、挿入順序の維持については何も言及されていません。実際には、まともなDBのほとんどもそれを維持していません。するとここで止まります。最初にテーブルを並べ替えても、高速にはなりません。関心のある列 (少なくとも で使用するもの) にインデックスを付けるだけですWHERE。
于 2010-08-10T14:39:00.980 に答える
3
標準的な方法はありません。
一部のデータベースでは、インデックスの並べ替え順序を指定できます。
SQL Serverでは、インデックスに ASC または DESC を記述できます。
[ASC | 説明 ]
特定のインデックス列の昇順または降順の並べ替え方向を決定します。デフォルトは ASC です。
MySQLでは、インデックスを作成するときに ASC または DESC を記述することもできますが、現在これは無視されています。将来のバージョンで実装される可能性があります。
于 2010-08-10T14:40:21.320 に答える
3
適切な RDBMS の「信条」の 1 つは、この種の問題は、DB を使用しているあなたや他の人に関係するべきではないということです。
DBエンジンは、レコードを保存/取得するために必要な方法を「自由に」使用できるため、「トップ」の動作を強制したい場合は、他の提案を実行してください。テーブル（またはテーブル）にタイムスタンプフィールドを追加し、インデックスを追加しますその上で、それをソートおよび/またはクエリ基準として使用してクエリを実行します（例：毎分テーブルをポーリングし、タイムスタンプ> = systime-1分のレコードを要求します）
于 2010-08-10T14:42:48.860 に答える
2
テーブルにカウンターまたは時間フィールドを追加し、並べ替えて上位の行を取得します。
つまり、SQL テーブルはデフォルトで特定の順序でアクセスされるという考えを忘れてください。seqscan は、最も古い行が最初に検索されることを意味するのではなく、すべての行がチェックされることのみを意味します。一部の検索を最適化したい場合は、一部のフィールドにインデックスを追加します。あなたが探しているのはおそらくインデックスです。
于 2010-08-10T14:37:46.680 に答える
2
- データがインデックス化されていれば問題ありません。インデックスは、シーケンシャル スキャンではなく、バイナリ検索を実行しています。
- あなたが
TOP 1（またはそのようなことを）していない限り、SELECTとにかくテーブル全体またはインデックスをスキャンする必要があります。
于 2010-08-10T14:38:09.880 に答える
1
あなたはこれを行うことはできません。
ただし、さらに良い方法があります。テーブルのデザインによっては、ほぼエントリの順序で物事を維持するインデックスを作成できるはずです。たとえば、自動インクリメントするidフィールドを作成する一般的な方法を採用している場合、そのインデックスはほぼ時系列になっています。
一部のRDBMSでは、後方インデックス、つまり昇順ではなく降順のインデックスを宣言できます。IDフィールドに後方索引を作成し、オプティマイザーがその索引を使用する場合、最新のエントリーが最初に調べられます。これにより、最初の行に迅速に応答できます。
次のステップは、オプティマイザーにインデックスを使用させることです。インデックスが使用されているかどうかを確認するには、explainplanを使用する必要があります。IDの降順で行を要求する場合、オプティマイザーはほぼ確実に後方インデックスを使用します。そうでない場合は、ヒントを使用してオプティマイザーをガイドできる場合があります。
時間を無駄にしないためにすべての行を読み取らないようにする必要がある場合は、LIMIT機能を使用して、たとえば10行のみ、または1行以上が必要であることを宣言できる場合があります。それはそれをする必要があります。
幸運を。
于 2010-08-10T15:25:30.837 に答える
1
実際に問題が発生するのに十分な行があり、「最後に挿入された行」の数がわかっている場合は、ラウンドアバウト方式を試すことができます。
注：かなり大きなテーブルの場合でも、これは効率が悪くなりますが、メインテーブルが十分に大きくなると、この作業がユーザー向けのパフォーマンスに驚かされるのを見てきました。
テーブルの構造を正確に模倣する「ステージング」テーブルを作成します。メインテーブルに挿入するときはいつでも、「ステージング」領域にも挿入してください。任意の最大値（たとえば、10,000または制限値）を超える新しい行に達したときに、トリガーを使用してテーブルの最小ID行を削除することにより、「ステージング」領域をn行に制限します。
次に、クエリは最初にその小さなテーブルにヒットして情報を探すことができます。テーブルは最後のn行に任意に制限されているため、最新のデータのみを検索します。それが一致するものを見つけられない場合にのみ、クエリ（実際には、この時点で意思決定のためのストアドプロシージャ）がメインテーブルにヒットします。
いくつかの落とし穴：
1）「メイン」テーブルと「ステージング」テーブルの間の正しい一致を維持するために、トリガーが適切に設定されていることを確認してください。
2）これは、適切に処理されない場合、すぐにメンテナンスの悪夢になる可能性があります。シナリオによっては、少し厄介になる可能性があります。
3）これが非常に特定のシナリオでのみ効率的/有用であることを十分に強調することはできません。一致しない場合は、他の回答のいずれかを使用してください。
于 2010-08-10T14:48:33.733 に答える
1
ISO/ANSI 標準 SQL は、最適化をまったく考慮していません。たとえば、広く認識されているCREATE INDEXSQL DDL は標準には含まれていません。これは、標準が基礎となるストレージ メディアについて何の想定もしていないためであり、想定すべきでもありません。私は定期的に SQL を使用してテキスト ファイルと Excel スプレッドシートのデータをクエリしていますが、どちらにもデータベース インデックスの概念はありません。
于 2010-08-10T15:24:16.160 に答える
0
テーブルに作成日がある場合は、それで並べ替えを逆にして、上位 1 を取得します。
于 2010-08-10T14:40:06.227 に答える