标签: materialized-view

我有一个包含 varchar 类型字段中的 XML 数据的表。该字段用于存储来自各种不同 XML 模式的数据，其中一些通过存储在另一个表中的记录相关联。

我最近创建了一些解析 XML 的视图，并且在某些情况下创建了一些值的枢轴。这些视图为我的报告提供了极好的数据，但对性能造成了严重影响。我想知道是否可以通过索引提高性能。

下面是一个视图的例子：

create view StudentHours as
  select
      x.TableRecordId as Id
    , x.RecordXml.value('(/TableRecord/LOGDate)[1]', 'DateTime') as LogDate 
    , x.RecordXml.value('(/TableRecord/LOGHours)[1]', 'float') as Hours
    , x.RecordXml.value('(/TableRecord/LOGApproved)[1]', 'varchar(10)') as Approved
    , y.PKTableRecordId as CourseId
  from
    (select TableRecordId, Cast([Schema] as Xml) as RecordXml 
     from TableRecords where TableSchemaId = 1857) as x
  join TableRecordRelations as y on x.TableRecordId = y.FKTableRecordId

然后，我将在其他执行聚合等操作的视图中使用此视图。

名为 TableRecords 的表在其唯一 id TableRecordId 上有一个索引，TableRecordRelations 在其重要字段上也有索引。

添加一两个索引是否有助于此视图的性能？是否需要更多数据来确定这一点？

当我插入具有聚集索引视图的表时，估计的执行计划似乎并行执行表插入和视图的聚集索引插入操作。

1. 这是真的？
2. 为什么 %s 加起来不是 100%？

下面是一个有点人为的例子。

/*
DROP INDEX [IX__AView] ON [dbo].[_AView]  
DROP VIEW _AView
DROP TABLE _A
*/

CREATE TABLE _A (Name VARCHAR(10) NOT NULL)
GO

CREATE VIEW _AView WITH SCHEMABINDING AS 
SELECT Name FROM [dbo]._A
GO

CREATE UNIQUE CLUSTERED INDEX [IX__AView] ON [dbo].[_AView] ([Name] ASC) 
GO

/*
--run the estimated execution on this
INSERT INTO _A (Name) values ('cheese')
*/

我有几个大表，我希望优化大约 60 亿行。集群键是 Epoch（Unix 日期时间，即 1970 年之后经过的秒数）和客户 ID。此表记录每个客户每种产品类型的使用数据。

例如，如果这是针对电信公司，则 TypeID 1 是本地电话，该值是该客户使用的分钟数。TypeID2 是国际电话，是该客户在那一小时内使用了多少分钟的值。假设 TypeID3 是国内通话的特殊折扣费率。

数据以 1 小时为间隔存储。我希望索引视图存储聚合的 24 小时值，因此当我们为每个客户运行 1 天的查询时，它只需在索引视图中查找 1 行而不是基表中的 24 行。

这是基表：

ColRowID (bigint)
AggregateID (int)
Epoch (int)
CustomerID (int)
TypeID  (tinyint)
ErrorID (smallint)
Value (int)

为了我们的报告目的，我们不关心 Aggregate 或 RowID，所以我认为索引视图将如下所示：

CREATE VIEW [ixvw_AggTbl]
WITH SCHEMABINDING
AS
SELECT Epoch, CustomerID, TypeID, ErrorID, SUM(Value)
FROM DBO.BaseTbl
-- GROUP BY Epoch  (what goes here?? Epoch/86400?  If I do that I have to 
-- put Epoch/86400 in the SELECT …

此页面https://msdn.microsoft.com/en-us/library/ms188276.aspx表示如果您想要嵌套的 XML（即 XML 树），那么您需要像这样设置查询：

SELECT Col1, 
       Col2, 
       ( SELECT Col3, Col4 
        FROM  T2
        WHERE T2.Col = T1.Col
        ...
        FOR XML AUTO, TYPE )
FROM T1
WHERE ...
FOR XML AUTO, TYPE;

（使用子查询）

这与索引视图的要求完全不一致（不允许子查询）。

有没有办法将这两个功能结合在一起？（有一个带有 XML 树的索引视图？）

我的问题的不足是： 如何在不使用任何子查询或联合的情况下从许多表创建 XML 树（即嵌套的 XML 节点）。（因此它将与 SQL Server 索引视图一起使用。）

仅供参考：不确定是否重要，但我的特定查询有超过 10 个级别的 xml 树（从一堆不同的表中提取）。

我有一个在 Postgresql 中创建的物化视图。我想知道有没有办法 pg_dump 物化视图，就好像它们是表一样，所以当我将它们导入另一个数据库时，它会将其视为表而不是从其他表创建的视图？

希望这个问题是不言自明的。我读过 MySQL 中不存在物化视图，但有时我会在EXPLAIN

有人可以帮我解决这个问题吗？如果物化视图在 MySQL 中不存在，“（物化）”是什么意思？使用 MySQL Server 5.6、Workbench 6.3。

当我尝试创建/更改视图来创建这样的索引时

CREATE UNIQUE CLUSTERED INDEX IDX_vSalPopulation\n   ON sfdc.vSalPopulation (ID);\n

我收到以下错误消息

\n

消息 1938，级别 16，状态 1，第 40 行 无法在视图\n\'vSalPopulation\' 上创建索引，因为基础对象 \'YR_TRM_SBTRM_TABLE\'\n 具有不同的所有者。

\n

当我检查表时，我发现这些表由不同的模式拥有

exec sp_tables \'dbo.YR_TRM_SBTRM_TABLE\'\nexec sp_tables \'vSalPopulation\'\n

\n

TABLE_QUALIFIER     TABLE_OWNER       TABLE_NAME              TABLE_TYPE    REMARKS\nMyDB                dbo               YR_TRM_SBTRM_TABLE      TABLE         NULL \nMyDB                sfdc              vSalPopulation          VIEW          NULL\n

Run Code Online (Sandbox Code Playgroud)\n

有关索引视图的文档指出，您不能拥有引用两个不同数据库的索引视图。

\n
• 必须使用该WITH SCHEMABINDING选项创建视图。
\n
• 该视图必须仅引用与该视图位于同一数据库中的基表。\n
\n
• 该视图不能引用其他视图。\xe2\x80\xa6 等
\n

但是，我有相同的数据库，但有两个不同的架构。也许问题实际上是第三个要求？虽然我没有引用其他视图，但还是有函数的。也许我误解了错误消息。权限？那么，一般来说，是否可以有一个索引视图来引用来自两个不同模式的对象？

给我同样错误的视图的简化定义如下所示

ALTER VIEW sfdc.vSalPopulation\n   WITH SCHEMABINDING \nAS\nSELECT DISTINCT\n    ID\nFROM …

我需要CREATE MATERIALIZED VIEW ... WITH DATA从函数/过程执行，但我得到了ERROR: CREATE MATERIALIZED VIEW ... WITH DATA cannot be executed from a function.

除了使函数返回创建查询文本并复制粘贴以执行它之外，还有其他解决方法吗？

看起来真的很傻，但我想这背后有一个很好的理由......无论如何，这个限制有什么解决方法吗？

我正在运行 postgresql 15。

在 SQL Server 中，索引视图是一个充满限制的地狱。但我需要一个。我有一个格式化程序 SQLCLR 函数，它创建域密钥的美化版本 - 用户希望能够搜索该美化版本的子字符串。因此，我需要持久计算列或物化视图上的全文索引。

但是，格式化程序依赖于存储在多个表中的数据。

因此，这适用于视图，但不适用于持久计算列，因为它们无法从多个表进行查询。

我的 SQLCLR 方法是精确且确定的，因此它应该适合在索引视图中使用，但索引视图的索引键中不能包含 SQLCLR。

我可以使用 T-SQL 函数重新实现我的格式化程序FORMAT...但也与索引视图不兼容FORMAT。