Mysql 为什么从视图检索数据与从该视图的基础选择检索数据时存在性能差异

我使用单个谓词在视图上执行查询，这将在4-7秒内为我提供记录，但当我尝试使用相同谓词并直接使用该视图中的基础查询检索记录时，它将在不到几秒钟内为我提供记录。我正在使用MySQL

我已经试着检查了这两个查询的执行计划，如果表中有数十万条记录，它会给出主要的区别

那么，有什么线索或想法可以解释为什么直接使用查询时性能更好

下面是我的视图定义

 SELECT    entity_info.source_entity_info_id      AS event_sync_id, 
          entity_info.source_system_id           AS source_system_id, 
          entity_info.target_system_id           AS destination_system_id, 
          event_sync_info.integrationid          AS integration_id, 
          event_sync_info.source_update_time     AS last_updated, 
          entity_info.source_internal_id         AS source_entity_internal_id, 
          entity_info.source_entity_project      AS source_entity_project, 
          entity_info.target_internal_id         AS destination_entity_internal_id, 
          entity_info.destination_entity_project AS destination_entity_project, 
          entity_info.source_entity_type         AS source_entity_type, 
          entity_info.destination_entity_type    AS destination_entity_type, 
          event_sync_info.opshub_update_time     AS opshub_update_time, 
          event_sync_info.entity_info_id         AS entity_info_id, 
          entity_info.global_id                  AS global_id, 
          entity_info.target_entity_info_id      AS target_entity_info_id, 
          entity_info.source_entity_info_id      AS source_entity_info_id, 
          ( 
                 SELECT Count(0) AS count(*) 
                 FROM   ohrv_failed_event_view_count failed_event_view 
                 WHERE  (( 
                                      failed_event_view.integration_id = event_sync_info.integrationid)
                        AND    ( 
                                      failed_event_view.entityinfo = entity_info.source_entity_info_id))) AS no_of_failures
FROM      (ohrv_entity_info entity_info 
LEFT JOIN ohmt_eai_event_sync_info event_sync_info 
ON        (( 
                              entity_info.source_entity_info_id = event_sync_info.entity_info_id)))
WHERE     ( 
                    entity_info.source_entity_info_id IS NOT NULL)

查询示例

从集成id=10的视图中选择*

此视图的执行计划为该视图中的子查询处理142668行

选择查询视图和集成的\u id=10

此文件的执行计划看起来不错，只处理所需的行

---

我认为问题在于以下问题：

SELECT * FROM view WHERE integration_id = 10;

这迫使MySQL具体化一个中间表，然后必须再次查询该表以应用

WHERE

子句中的限制。另一方面，在第二个版本中：

SELECT (QUERY_OF_VIEW with WHERE integration_id = 10)

MySQL不必在视图本身中具体化查询以外的任何内容。也就是说，在您的第二个版本中，MySQL只需在视图中执行查询，而无需任何后续子查询。

参考此文档，这取决于是否可以使用合并算法，但如果不适用，则必须生成新的临时表以查找数据关系，您还可以看到，讨论优化以及何时使用视图和何时不应该使用视图

如果不能使用合并算法，则必须使用临时表 相反如果视图包含以下内容之一，则无法使用“合并” 以下结构：

聚合函数（SUM（）、MIN（）、MAX（）、COUNT（）等）

明显的

分组

拥有

极限

联合还是全体联合

选择列表中的子查询

仅指文字值（在本例中，没有基础 表1）

---

谢谢，因为构建的视图非常复杂，所以有哪些替代方案。检索结果时，我还需要分页。我尝试使用函数并将参数传递给视图的底层定义，但MySQL对函数有限制，它无法返回表。线程链接：。无论我选择何种方式来解决这个问题，都需要与Oracle、MSSQL和HSQL一起工作。如果视图不符合您的需要，那么您应该更改视图，或者创建一个新的视图。在大多数SQL版本中，视图是廉价的，假设它们没有具体化。