我正在尝试优化使用MySQL 5.1中的视图的查询。似乎即使我从视图中选择1列，它始终会进行全表扫描。那是预期的行为吗？
该视图只是我在下面的第一个查询中指定的表的SELECT“这些表中的所有列-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)
MySQL中的视图未编制索引，因此就其本质而言，每次访问时都需要进行全面扫描。一般而言，这使Views仅在以下情况下才真正有用：您有一个相当复杂的静态查询，该查询返回一个很小的结果集，并且您计划每次都获取整个结果集。
编辑： 当然，视图将使用基础表上的索引，以便对视图本身进行优化（否则它们将毫无意义），但是由于视图上没有索引，因此WHERE不可能在要优化的视图上查询。
为Views构造索引无论如何都是昂贵的，因为尽管我没有尝试分析任何Views，但我相当确定在幕后构造了一个临时表，然后返回了结果集。构造临时表已经花费了很多时间，我不希望这样的视图也试图猜测需要哪些索引。这就提出了第二点，即MySQL当前不提供一种指定用于View的索引的方法，因此它如何知道需要对哪些字段进行索引？它会根据您的查询猜测吗？
您可能考虑使用临时表，因为这样您可以在临时表中的字段上指定索引。但是，根据经验，这往往非常缓慢。
如果此视图包含的全部是SELECT ALL FROM table1，table2，table3；那么我不得不问为什么这个查询根本需要在View中？如果出于某种原因它绝对必要，则您可能希望使用存储过程来封装查询，因为这样您就可以获得最佳性能，同时保持对结果集的数据库调用更为简单的好处。
