场景描述：报表功能，单个物化视图基表为4–6张，有数据持续写入但是写入不是很频繁，能够接受物化视图更新延迟小时为单位，数据量大约30w,相关表只涉及查询。
痛点描述：目前是通过定时任务视图转换成实体表，提高效率，但是维护成本高，运维较为复杂
功能描述：手动更新能力有一定的价值
使用意向：使用需求强，可以接受手动更新能力。
场景描述：您当前业务中的哪些场景需要物化视图功能？统计用户数据
单个物化视图的基表（数据源）有几张表？三四个
是否有持续数据写入？每天定时写一次
相关表是否存在更新或者删除操作？有删除操作
痛点描述：您的系统是如何支持这些业务的，有遇到哪些痛点？ 当前都是定时任务来算
功能描述：物化视图你需要哪些功能？主要是关联计算（例如：过滤，关联，聚集，分区等）手动更新能力对于您的业务有价值吗？有
使用意向：在提供自动更新能力之前，先提供手动更新功能，您会在业务中使用吗？ 会
在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图，您会在业务中使用吗？ 会
- 场景描述：
- 当前的公司是做物联网，随着业务的扩展 ，越来越多的设备需要与数据库进行数据交互，需要使用到MV；
- 单个物化视图的基表4~8张；
- 数据写入需立即或者定时更新；
- 延时不低于1h；
- 单个视图数据在百万以上，存在大量更新操作；
-
痛点描述：
无法处理大规模的设备数据，复杂的查询操作困难，不方便分析和处理物联网领域的大数据。 -
功能描述：
- 过滤，关联，聚集，分区等都需要
- 需要手动更新能力
- 使用意向：
- 会先使用手动更新，会在业务中使用
1.场景描述
业务需要多表关联取数据
2.痛点描述
多个大表关联导致数据库性能低,取数据慢
3.功能描述
物化视图增量的方式,类似oracle增量物化视图,比如按天增量物化视图
4.使用意向
会使用,首次取全量,后续通过增量方式同步物化视图,性能肯定有较大提升
可以直接参考starrocks/doris的增量物化视图，按分区来更新；
有了物化视图可以省去聚合表的烦劳；
或者改进tiflash的性能，使其能达到doris的高度
1.场景描述
需要多表计算数据
2.痛点描述
现在是大数据平台抽取后计算推会数据库
3.功能描述
类似oracle增量物化视图可以增量更新
4.使用意向
考虑系统稳定性，先观望
- 场景描述：
对外提供类似字典的数据，源表是从多个表中通过复杂逻辑组装的数据，数据有更新 - 痛点描述：
视图方法，运行较慢，频繁使用比较耗性能； - 功能描述：
需要过滤，关联，聚集 - 使用意向：
会，总比现在的方式好；
需要，物化视图对于OLAP来说是很有必要的
-
场景描述：
每日定期提前算好多表join的数据，方便后续直接高效使用。 -
痛点描述：
只能从源表取数，慢，而且容易OOM -
功能描述：
需要手动+定时更新的功能，可以进行多表的关联、过滤、聚集等 -
使用意向：
当然会考虑使用，现在是通过定时任务去更新集群上表
我能想到一个问题就是原来oracle下会生成海量规定日志，不知道tidb物化视图会不会生成很多binlog。希望产品经理在设计过程中要注意。
- 场景描述：
主要还是实时数据场景。单个物化视图的基表2-4张左右，不能太大。有实时的也有每天统一处理的。秒级延迟吧。单个物化视图的数据量不多100多G。删除更新均有一些，不多。 - 痛点描述：
管理复杂度问题吧，刷新策略的配置。 - 功能描述：
物化视图你需要哪些功能？越多越好吧，标准化配置，简单上手。 - 使用意向：
在提供自动更新能力之前，先提供手动更新功能，您会在业务中使用吗？在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图，您会在业务中使用吗？ 基本都是靠DBA人肉。
- 场景描述：
推广网站需要统计VU/PV、用户数据分析等，物化视图的基表5~10张左右，单个表的数据量大概在1000万左右，数据需要实时更新； - 痛点描述：
数据量大运行较慢，存在多表join操作，对数据库性能产生较大影响； - 功能描述：
需要过滤，关联，聚集等 - 使用意向：
会
一、场景描述
每天处理大量的用户行为数据。需要经常对不同用户进行用户行为等进行深入分析，制定考核指标。同时，运营团队也需要实时了解关键业务指标的变化，以便快速做出决策。
二、痛点描述
- 数据查询缓慢：在处理大规模数据时，常规的查询操作可能非常耗时，导致分析和决策的延迟。特别是在高峰时段，多个用户同时进行复杂查询时，系统响应时间过长。
- 资源消耗大：频繁进行复杂查询会消耗大量的计算资源和存储资源，影响系统的整体性能和稳定性。
- 数据不一致：由于数据不断更新，不同时间点的查询结果可能不一致，给决策带来困扰。
三、功能描述
- 预先计算和存储：物化视图可以根据特定的查询需求，预先计算并存储结果。这样，在实际查询时，可以直接从物化视图中获取结果，大大提高查询速度。
- 自动更新：可以设置物化视图的更新策略，确保其数据与源数据保持同步。例如，可以定时更新或在源数据发生重大变化时自动更新。
- 优化查询性能：通过合理设计物化视图，可以针对特定的查询场景进行优化，减少查询的复杂性和资源消耗。
- 数据一致性保证：确保物化视图中的数据与源数据的一致性，提供可靠的分析基础。
四、使用意向
会
菜鸟小白不懂什么叫物化视图，但是搜索了下，并且在一排评论看下来之后，也明白了一些。
这就是我一直想要的功能
1、 解释：对于普通视图而言，其真实数据在基表中，即每次查询视图都是需要执行查询语句。
有时候为了防止每次都查询，将结果集存储起来，这种有真实数据的视图，称为物化视图。
2、现状1：目前很多ap类在tidb上查不出结果，只能移交大数据做处理，优点是可以统一大模型提供给业务方使用。缺点也很明显：大数据人员有限，ap类报表分析在工单里排得遥遥无期。往往要延两周才有结果，还要时不时面对业务方报表加塞。
3、现状2：业务数据需要我们出逻辑，大数据处理数据。逻辑变动就需要再次排期。对于双方而言都是非常痛苦的过程
4、现状3：能在tidb中实现的报表，担心影响到数据库使用性能。专门走单独部署的节点做计算，但与其他节点内存共用，业务高峰期依旧不敢使用。因此都是定时任务处理之后新塞到一张表中。有需要每天重算的数据为了防止冗余还要每天清理，经常会导致表健康度快速下降。
5、结论：基于这些情况，如果有物化视图，从技术实现上来讲，简直不要太美好。必然会使用
2 个赞
我可以不用，你不能没有。 
需要需要，社区版还需要全文检索、存储过程、同义词、dblink等等。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。