在传统的mssql里面可以使用临时表的语法#temp，实现对一个大表的实体表做过滤，在后面用过滤后的数据再处理
这种业务应用场景在TiDB里面应如何操作？
-
在当前的 TiDB 集群中暂时不支持临时表的特性:
-
如果要实现临时表的功能，需要在业务实现中，创建普通的堆表，只是该表作为临时表使用，使用完毕后，需要手动清理该表，如
drop或truncate~ -
如果对临时表有相应的需求，可以在 github 上提交相应的 feature request ：
非常感谢
官网的提到的限制我们了解到了，我们公司现在尝试把mssql的应用迁移到TiDB上面
目前业务大量用到了SSRS的报表里面使用了临时表的语法，对应TiDB的应用场景，请问有什么策略？
如创建一个实体堆表，每个客户端都访问会造成数据混乱
视图不能满足你的需求么？ 必须临时表？ 是带什么特别的需求么？
可以看下视图的一些定义
视图
TiDB 支持视图，视图是一张虚拟表，该虚拟表的结构由创建视图时的 SELECT 语句定义。使用视图一方面可以对用户只暴露安全的字段及数据，进而保证底层表的敏感字段及数据的安全。另一方面，将频繁出现的复杂查询定义为视图，可以使复杂查询更加简单便捷。
查询视图
查询一个视图和查询一张普通表类似。但是 TiDB 在真正执行查询视图时，会将视图展开成创建视图时定义的 SELECT 语句，进而执行展开后的查询语句。
查看视图的相关信息
通过以下方式，可以查看 view 相关的信息。
使用 SHOW CREATE TABLE view_name 或 SHOW CREATE VIEW view_name 语句
TiDB 目前不支持临时表，如果要迁移的话，可能要考虑从业务层面去调整下。
非常感谢大家回复
在传统报表环境里面，dba习惯用temp把一个大的数据集临时过滤成小数据集，在后续做join，可能这个处理后的结果集只是针对当前报表的业务逻辑，如用view，会在dw层产生大量view而且这些view只针对某个报表
可能还是一个数据仓分层划分的问题，怎么规划和规避这种问题
建议可以提交 feature https://github.com/pingcap/tidb/issues/new/choose
你这说的是ETL 的处理方式啊，这种方案通用型也太差了…
建议规划新的平台来解决这个问题
可以考虑下 Flink + TiDB ,看下能否解决你的具体需求。
谢谢，TIDB里面UDF不支持，如要进行类似大表的递归运算，目前想到的方案是，在调度平台用python读取tidb，实现业务逻辑后回写到tidb，这种对调度平台硬件开销也不小，一次逻辑运算读取的表数据还是很多
除了Flink外
有什么好的建议方案吗？
请问都是很大的表，并且频率很高吗？ 有可能改为 子查询嵌套子查询吗？
除了表大外，还有一些聚合和函数运算，之前是用的表值函数和临时表
那可能要等临时表了，估计功能要在下半年了吧