MySQL视图是不是总是进行全表扫描？
Posted
技术标签:
【中文标题】MySQL视图是不是总是进行全表扫描？【英文标题】：Does MySQL view always do full table scan?MySQL视图是否总是进行全表扫描？ 【发布时间】：2010-10-12 20:19:41 【问题描述】：我正在尝试优化在 mysql 5.1 中使用视图的查询。似乎即使我从视图中选择 1 列，它也总是会进行全表扫描。这是预期的行为吗？
对于我在下面第一个查询中指定的表，该视图只是一个 SELECT "All Columns From These Tables - NOT *"。
这是我从构成视图的查询中选择索引列 PromotionID 时的解释输出。如您所见，它与视图上的输出有很大不同。
EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: pc
type: const
possible_keys: PRIMARY,fk_pc_pb
key: PRIMARY
key_len: 302
ref: const
rows: 1
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: pb
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
*************************** 3. row ***************************
id: 1
select_type: SIMPLE
table: pct
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
3 rows in set (0.00 sec)
当我从视图中选择相同的东西时的输出
EXPLAIN SELECT vpc.PromotionID FROM vw_PromotionCode vpc WHERE vpc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 5830
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DERIVED
table: pcart
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 33
Extra: Using index
*************************** 3. row ***************************
id: 2
select_type: DERIVED
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcart.PromotionID
rows: 1
Extra:
*************************** 4. row ***************************
id: 2
select_type: DERIVED
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 5. row ***************************
id: 3
select_type: UNION
table: pp
type: index
possible_keys: PRIMARY
key: pp_p
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 6. row ***************************
id: 3
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pp.PromotionID
rows: 1
Extra:
*************************** 7. row ***************************
id: 3
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 8. row ***************************
id: 4
select_type: UNION
table: pcp
type: index
possible_keys: PRIMARY
key: pcp_cp
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 9. row ***************************
id: 4
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcp.PromotionID
rows: 1
Extra:
*************************** 10. row ***************************
id: 4
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 11. row ***************************
id: 5
select_type: UNION
table: ppc
type: index
possible_keys: PRIMARY
key: ppc_pc
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 12. row ***************************
id: 5
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppc.PromotionID
rows: 1
Extra:
*************************** 13. row ***************************
id: 5
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 14. row ***************************
id: 6
select_type: UNION
table: ppt
type: index
possible_keys: PRIMARY
key: ppt_pt
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 15. row ***************************
id: 6
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppt.PromotionID
rows: 1
Extra:
*************************** 16. row ***************************
id: 6
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 17. row ***************************
id: NULL
select_type: UNION RESULT
table: <union2,3,4,5,6>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra:
17 rows in set (0.18 sec)
【问题讨论】：
【参考方案1】：MySQL 中的视图没有索引，因此从本质上讲，每次访问它们时都需要进行完整扫描。一般来说，这使得 Views 仅适用于您有一个相当复杂的静态查询并返回一个小结果集并且您计划每次都获取整个结果集的情况。
编辑： 当然，视图将使用基础表上的索引，以便优化视图本身（否则它们根本没有任何使用意义）但是因为没有索引在视图上，不可能优化视图上的 WHERE 查询。
无论如何，为视图构建索引会很昂贵，因为虽然我没有尝试分析任何视图，但我相当肯定临时表是在幕后构建的，然后返回结果集。构建临时表已经花费了大量时间，我不想要一个也试图猜测需要哪些索引的视图。这就引出了第二点，即 MySQL 目前没有提供一种方法来指定视图使用哪些索引，那么它如何知道需要索引哪些字段？它会根据您的查询猜测吗？
您可以考虑使用Temporary Table，因为这样您就可以在临时表中的字段上指定索引。但是，根据经验，这往往非常非常缓慢。
如果这个视图只包含一个 SELECT ALL FROM table1, table2, table3;那么我不得不问为什么这个查询需要在视图中？如果出于某种原因绝对有必要，您可能希望使用存储过程来封装查询，因为这样您将能够获得优化的性能，同时保持对结果集的数据库调用更简单的好处。
【讨论】：
这里dev.mysql.com/doc/refman/5.0/en/view-restrictions.html 说视图将使用基础表的索引。 我很确定你是对的——对 MySQL 视图的查询可以使用来自其源表的索引。您只是不能在视图本身上有索引，因此不能有一个索引包含来自多个表中的列。 不幸的是，这并不能解释为什么第二个查询被 MySQL 优化得如此糟糕。我所能想到的可能是这种观点并没有完全按照它的意图加入。不过不知道。 如果您在 View 上使用 WHERE 语句，则必须执行全表扫描以查找与 WHERE 子句匹配的值，因为 View 本身没有被索引。【参考方案2】：我已经深入研究了它，我错过了一个关键信息点 :( 我的视图查询实际上与另一个表有一个联合。这导致视图使用 TEMPORARY TABLE 算法而不是 MERGE 算法。
TEMPORARY TABLE 算法不允许在基础表中使用索引。
这似乎是 MySQL 中的一个错误，早在 2006 年就已报告，但看起来它在 2009 年并未解决！ http://forums.mysql.com/read.php?100,56681,56681
看起来我只需要将查询重写为外部连接。
【讨论】：
以上是关于MySQL视图是不是总是进行全表扫描？的主要内容，如果未能解决你的问题，请参考以下文章