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?
