1

「users」という名前のテーブルがあるとしましょう。作成のコード:

CREATE TABLE IF NOT EXISTS users 
(id_user INTEGER PRIMARY KEY AUTOINCREMENT, 
 username VARCHAR(32) COLLATE NOCASE, 
 passwd_hash VARCHAR(255) NOT NULL DEFAULT '', 
 passwd_salt VARCHAR(255) NOT NULL DEFAULT '', 
 email_addr VARCHAR(255) NOT NULL DEFAULT '');


CREATE INDEX IF NOT EXISTS idx_id_user ON users (id_user ASC);
CREATE INDEX IF NOT EXISTS idx_username ON users (username ASC);

プレーヤーがサーバーに参加すると、プレーヤーのユーザー名が登録されているかどうかがチェックされます。

SELECT id_user 
FROM users 
WHERE username = '%s' LIMIT 1

ユーザー名が登録されている場合、プレイヤーはログインを求められます。ログインを試みると、次のようになります。

SELECT passwd_hash, passwd_salt 
FROM users 
WHERE id_user = %d

次に、両方のパスワードが一致するかどうかを明らかにチェックします。

私の質問は、インデックスを作成する必要がpasswd_hashありますか?passwd_salt

4

4 に答える 4

4

クエリを実行すると:

SELECT passwd_hash, passwd_salt
FROM users
WHERE id_user = %d;

SQL エンジンは、インデックスを使用して正しいレコードを見つけます。select次に、テーブル自体に移動して、句に必要なデータを取得します。

代わりに、次のようにインデックスを構築する場合:

CREATE INDEX IF NOT EXISTS idx_id_user ON users (id_user ASC, paswd_hash, passwd_salt);

次に、SQL エンジンは、インデックスを使用するだけでクエリを満たすことができます。これにより、パフォーマンスが向上する可能性があります。得られるものはごくわずかです。

これは一般的な原則ですが、例外もあります。一部のデータベースは、データ列のクラスター化インデックスの概念をサポートしています。このようなインデックスでは、テーブル内のデータをキーで並べ替える必要があり、テーブル自体がインデックスとして機能します。ただし、これは SQLite インデックス オプションではありません。

于 2013-07-28T17:47:15.857 に答える
4

3 列のインデックス (userid、password_hash、password_salt) を作成します。これは、より効率的な カバーインデックスとして使用できます。

これは SQLite の小さな改善に過ぎないように見えますが、この概念は、インデックスを RAM にキャッシュできる他の RDBMS 実装でより大きな利益を得るために使用されます。

http://www.sqlite.org/queryplanner.html言います:

1.7 インデックス
のカバー 「カリフォルニア オレンジの価格」クエリは、2 列のインデックスを使用することでより効率的になりました。しかし、SQLite は、"price" 列も含む 3 列のインデックスを使用すると、さらにうまく機能します。

この新しいインデックスには、クエリで使用される元の FruitsForSale テーブルのすべての列 (検索語と出力の両方) が含まれています。これを「カバリングインデックス」と呼んでいます。必要な情報はすべてカバリング インデックスにあるため、SQLite は価格を見つけるために元のテーブルを参照する必要はありません。

したがって、インデックスの最後に追加の「出力」列を追加することで、元のテーブルを参照する必要がなくなり、クエリのバイナリ検索の数を半分に減らすことができます。これは、一定の要因によるパフォーマンスの向上です (速度が約 2 倍になります)。しかし一方で、それは単なる洗練でもあります。2 倍のパフォーマンスの向上は、テーブルが最初にインデックス付けされたときに見られた 100 万倍の向上ほど劇的ではありません。また、ほとんどのクエリでは、1 マイクロ秒と 2 マイクロ秒の違いに気付くことはほとんどありません。

私のプレゼンテーションHow to Design Indexes, Really を読むことに興味があるかもしれません。私は MySQL ユーザー向けにプレゼンテーションを行いましたが、その概念は SQLite や他のほとんどの RDBMS にも関連しています。

于 2013-07-28T18:04:41.080 に答える
1

いいえ。クエリを実行する列にのみインデックスを付ける必要があります。

レコードが見つかると、インデックスはそのレコード内の他の列をより速く取得するのに役立ちません。

于 2013-07-28T17:42:03.020 に答える
0

いいえと思います。パスワード情報を効率的に取得するのに十分な id_user に作成されたインデックスがあります。確かに、取得するという理由だけですべてのフィールドにインデックスを作成するわけではありません。

于 2013-07-28T17:54:40.253 に答える