2

ユーザーが自分のファイルのクリックに興味を持っているファイル共有サイトがあります。各クリックは、クリックテーブルに新しい行として保存されます。

通常、特定の日付範囲でクリック数を知りたいと考えています。

$statement = $db->prepare("SELECT COUNT(DISTINCT ip) FROM clicks WHERE user_id=? AND time BETWEEN ? AND ?");
$statement->execute(array($user_id, $from_date, $to_date));

さらに、特定のファイルのクリック数も確認できます。

$statement = $db->prepare("SELECT COUNT(DISTINCT ip) FROM clicks WHERE file_id=? AND time BETWEEN ? AND ?");
$statement->execute(array($file_id, $from_date, $to_date));

これらのクエリの問題は、user_idとfile_idがこのテーブルのキーではないことです（これらは一意ではありません）。代わりに、単純な「id」列が主キーですが、どのクエリにも影響を与えることはありません。

クラスター化インデックスを調査してきましたが、この場合の実装方法がわかりません。

クリックテーブルがかなり大きくなる（500万から600万行）ので、これらのクエリはより長くかかります（そして私はこのテーブルがもっと大きくなることを計画しています）。パーティショニングが私がしなければならないことかもしれないと読みましたか？

クラスタ化されたキーを作成するか、テーブルをパーティション化するか、またはその両方を行う必要がありますか？

参考までに、clicks構造は次のとおりです。

id time user_id ip file_id

4

1 に答える 1

3

クラスタ化インデックスを変更する必要はありません。

これらのインデックスを作成することをお勧めします。

ALTER TABLE clicks ADD INDEX (file_id, time, ip),
                   ADD INDEX (user_id, time, ip);

インデックス定義にipを含めることにより、各クエリはインデックス構造自体から必要なすべての情報を取得できる必要があります。これはカバーリングインデックスと呼ばれます。そうすれば、クエリはテーブルにまったく触れる必要がなくなるため、テーブルのクラスター化インデックスを構成する列は関係ありません。

EXPLAINを使用してクエリを分析すると、[追加]フィールドに[インデックスの使用]が表示されます。これは、クエリがカバーインデックスのメリットを享受していることを示しています。

MySQLパーティショニングでは、パーティション列がテーブルの主キー/一意キーの一部である必要があるため、この場合、パーティショニングが役立つとは思いません。

于 2012-12-13T02:46:34.200 に答える