sql – 如何正确索引很多关联表？

Movies       Actors       Movies_Actors
------       ------       -------------
movie_ID     actor_ID     FK_movie_ID
title        name         FK_actor_ID

…关联表(“Movies_Actors”)应如何索引以获得最佳读取速度？

我通常看到这只是在关联表中使用复合主键,就像这样：

CREATE TABLE Movies_Actors (
  FK_movie_ID INTEGER,FK_actor_ID INTEGER,PRIMARY KEY (FK_movie_ID,FK_actor_ID)
)

但是,这个索引似乎只能在搜索movie_ID和actor_ID时有用(尽管我不确定复合索引是否也适用于各个列).

既然“电影X”中的“演员都是什么”以及“曾经演员的电影”将是这张表的常见查询,似乎每个专栏都应该有一个单独的索引,以便自己快速找到演员和电影.综合指数有效地做到这一点吗？如果没有,那么在这个表上,复合索引似乎没有意义.如果一个组合索引是无意义的,那么如何处理一个主键呢？候选键显然是两列的组合,但是如果所得到的复合索引是无意义的(它不能是？)似乎是一种浪费.

另外,this link增加了一些混淆,并且表明,甚至可以实际指定两个组合索引(FK_movie_ID,FK_actor_ID),另一个作为(FK_actor_ID,FK_movie_ID),并选择哪个是主键(因此通常是聚类的),而“只是”一个独特的复合索引则基于哪个方向被查询得更多.

真正的故事是什么？复合索引是否自动有效地为每列搜索索引？最佳(读取速度,非大小)关联表在每个方向上是否具有复合索引,每列有一个？什么是幕后机械师？

编辑：我发现这个相关的问题,由于某些原因,我没有找到发布之前…
How to properly index a linking table for many-to-many connection in MySQL?

解决方法

(although I’m not certain on whether a
composite index also works for the
individual columns).

是的,它可以.但只有前缀：http://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys

Also,this link adds some confusion
and indicates that it might even be
useful to actually specify two
composite indices… one of them as
(FK_movie_ID,and the
other in reverse as (FK_actor_ID,
FK_movie_ID),

这其实是要做的事情.

取一个作为聚类索引,另一个作为非聚类索引,无论如何都包含聚类索引关键字,因此不需要再次包含该列(thx到JNK).

CREATE CLUSTERING INDEX a on Movies_Actors (fk_movie_id,fk_actor_id);
CREATE NONCLUSTERING INDEX b on Movies_Actors (fk_actor_id);

What is the real story?

http://Use-The-Index-Luke.com/

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!