视图和临时表哪个查询效率高？

[ggsysy]

在做查询报表的时候，经常有一些数据是需要关联的，比如 品类集合。
比如销售报表、采购报表、库存报表等，都经常需要关联这个品类集合，那么我之前都是在每个查询报表中，把品类集合插入到临时表后进行关联的。如果我把这个品类集合做成一个视图，后续的报表直接关联这个视图，查询效率会提高吗？
哪种方法比较好？或者有无更好的方法推荐一下？谢谢

[gw6328]

一个查询写不出来吗？我很少在项目中用临时表，当然你说的视图我也很少用。即使很复杂的动态报表，感觉也能一个存储过程搞定！

[饮水需思源]

我一般是固定格式的用视图，否则用临时表

[顺势而为1]

很多报表,多个存储过程都会用到 品类集合， 把 品类集合 建成视图相比于临时表， 只是减少SQL代码的重写， 对效率提高不会有帮助

[datafansbj]

结贴吧，就像高铁和飞机哪个运输效率高一样，永远没有绝对的答案。

[小野马1209]

临时表比较快，把需要的数据提取出来再去关联

[qq_38920801]

临时表比较好

[文盲老顾]

引用 75 楼 gw6328 的回复:

一个查询写不出来吗？我很少在项目中用临时表，当然你说的视图我也很少用。即使很复杂的动态报表，感觉也能一个存储过程搞定！

事实上，临时表和视图都很有用 比如一个无限级分类，如果想获得某一个分类的完整路径，用sql查询当然可以，但每次都写一遍很麻烦，而且，不是很标准，当结构略有调整，需要修改的地方就太多了，这个时候通常用视图来代替大部分查询指令 另一个就是在很大的数据量上查询，比如300万数据，查询正文中包含某个关键字的内容，且满足其他条件，由于表结构相对字段较多，用复合了很多字段的索引肯定不合适，这个时候一般都是用临时表，将符合关键字的主键值扔到临时表后，再inner join原始表查询，效率比一个指令写下所有查询高出太多了，没有可比性了都

[gw6328]

引用 78 楼 文盲老顾 的回复:

[quote=引用 75 楼 gw6328 的回复:] 一个查询写不出来吗？我很少在项目中用临时表，当然你说的视图我也很少用。即使很复杂的动态报表，感觉也能一个存储过程搞定！

事实上，临时表和视图都很有用 比如一个无限级分类，如果想获得某一个分类的完整路径，用sql查询当然可以，但每次都写一遍很麻烦，而且，不是很标准，当结构略有调整，需要修改的地方就太多了，这个时候通常用视图来代替大部分查询指令 另一个就是在很大的数据量上查询，比如300万数据，查询正文中包含某个关键字的内容，且满足其他条件，由于表结构相对字段较多，用复合了很多字段的索引肯定不合适，这个时候一般都是用临时表，将符合关键字的主键值扔到临时表后，再inner join原始表查询，效率比一个指令写下所有查询高出太多了，没有可比性了都[/quote] 每次都写一遍有点搞笑哈，如果经常用到结构性的东西就不是视图和临时表的讨论了，为什么不直接一个表？你要明白临时表是用之前要写，用完要处理掉，如果不处理的或者长期保存的为什么要这样？ 还有一点我表达的主要是实际的情况，如果经常视图，临时表代替查询的，我只能说sql写得很low.确实见过，比如一个存储过程上千行的东西，但是让别人改造一下，一个查询搞定！一个查询在索引的使用方面我感觉比临时表要好，因为用的就是原生，你非要用临时表写数据，建索引，再查询，再销毁，我感觉很累！干脆就建个表得了！ 再说一个视图吧，其实微软也推荐了视图的一些主要的应用场景，比如字段权限，开窗。或者对于维护性的东西不原意改表建表，这们确实省很大部工作。系统对接，开放表结构用视图确实比较方便。 但是用来纯为了当成子查询，我认为没有什么优化的效果。

[文盲老顾]

引用 79 楼 gw6328 的回复:

[quote=引用 78 楼 文盲老顾 的回复:] [quote=引用 75 楼 gw6328 的回复:] 一个查询写不出来吗？我很少在项目中用临时表，当然你说的视图我也很少用。即使很复杂的动态报表，感觉也能一个存储过程搞定！

事实上，临时表和视图都很有用 比如一个无限级分类，如果想获得某一个分类的完整路径，用sql查询当然可以，但每次都写一遍很麻烦，而且，不是很标准，当结构略有调整，需要修改的地方就太多了，这个时候通常用视图来代替大部分查询指令 另一个就是在很大的数据量上查询，比如300万数据，查询正文中包含某个关键字的内容，且满足其他条件，由于表结构相对字段较多，用复合了很多字段的索引肯定不合适，这个时候一般都是用临时表，将符合关键字的主键值扔到临时表后，再inner join原始表查询，效率比一个指令写下所有查询高出太多了，没有可比性了都[/quote] 每次都写一遍有点搞笑哈，如果经常用到结构性的东西就不是视图和临时表的讨论了，为什么不直接一个表？你要明白临时表是用之前要写，用完要处理掉，如果不处理的或者长期保存的为什么要这样？ 还有一点我表达的主要是实际的情况，如果经常视图，临时表代替查询的，我只能说sql写得很low.确实见过，比如一个存储过程上千行的东西，但是让别人改造一下，一个查询搞定！一个查询在索引的使用方面我感觉比临时表要好，因为用的就是原生，你非要用临时表写数据，建索引，再查询，再销毁，我感觉很累！干脆就建个表得了！ 再说一个视图吧，其实微软也推荐了视图的一些主要的应用场景，比如字段权限，开窗。或者对于维护性的东西不原意改表建表，这们确实省很大部工作。系统对接，开放表结构用视图确实比较方便。 但是用来纯为了当成子查询，我认为没有什么优化的效果。 [/quote] 好吧，来个实际点的命题 数据库中存在文章表（50万），产品表（300万），企业表（10万），综合搜索，查询出包含特定关键字的内容（关键字不可预知），以上3个表数据约40Gb以上，并发频率约200次/秒，问怎么设计数据库查询效率较高，其中三个原始数据表的表结构不可变动，可以使用存储过程、冗余表，触发器等一些列你认为可以提高效率的东西

[gw6328]

引用 80 楼 文盲老顾 的回复:

[quote=引用 79 楼 gw6328 的回复:] [quote=引用 78 楼 文盲老顾 的回复:] [quote=引用 75 楼 gw6328 的回复:] 一个查询写不出来吗？我很少在项目中用临时表，当然你说的视图我也很少用。即使很复杂的动态报表，感觉也能一个存储过程搞定！

事实上，临时表和视图都很有用 比如一个无限级分类，如果想获得某一个分类的完整路径，用sql查询当然可以，但每次都写一遍很麻烦，而且，不是很标准，当结构略有调整，需要修改的地方就太多了，这个时候通常用视图来代替大部分查询指令 另一个就是在很大的数据量上查询，比如300万数据，查询正文中包含某个关键字的内容，且满足其他条件，由于表结构相对字段较多，用复合了很多字段的索引肯定不合适，这个时候一般都是用临时表，将符合关键字的主键值扔到临时表后，再inner join原始表查询，效率比一个指令写下所有查询高出太多了，没有可比性了都[/quote] 每次都写一遍有点搞笑哈，如果经常用到结构性的东西就不是视图和临时表的讨论了，为什么不直接一个表？你要明白临时表是用之前要写，用完要处理掉，如果不处理的或者长期保存的为什么要这样？ 还有一点我表达的主要是实际的情况，如果经常视图，临时表代替查询的，我只能说sql写得很low.确实见过，比如一个存储过程上千行的东西，但是让别人改造一下，一个查询搞定！一个查询在索引的使用方面我感觉比临时表要好，因为用的就是原生，你非要用临时表写数据，建索引，再查询，再销毁，我感觉很累！干脆就建个表得了！ 再说一个视图吧，其实微软也推荐了视图的一些主要的应用场景，比如字段权限，开窗。或者对于维护性的东西不原意改表建表，这们确实省很大部工作。系统对接，开放表结构用视图确实比较方便。 但是用来纯为了当成子查询，我认为没有什么优化的效果。 [/quote] 好吧，来个实际点的命题 数据库中存在文章表（50万），产品表（300万），企业表（10万），综合搜索，查询出包含特定关键字的内容（关键字不可预知），以上3个表数据约40Gb以上，并发频率约200次/秒，问怎么设计数据库查询效率较高，其中三个原始数据表的表结构不可变动，可以使用存储过程、冗余表，触发器等一些列你认为可以提高效率的东西[/quote] 这个叫临时表? 我假设你全部都要查询，这种如果不考虑换其他类型数据库，用空间换时间，提前把关键词提取出来，我认为这种就是永久临的表了。 但是我可以说你这个数据一点都不多。按你上面的回答是想提取关键字，写入临时表，再来查哦？

[文盲老顾]

问题在于，关键字不可预知，我在实际使用中，每天检索的关键字超过几万个，你不可能为每个关键字建立永久性冗余表，那样冗余数据的结构就算再简单，数据量也会超过千亿级别，效率不一定有提高 再一个就是，即便你建立了永久临时表，即冗余表，维护这个冗余数据也是一个很占用资源的事情，每次修改以前的信息，再按照几十万的关键字从新更新一遍永久临时表，不太现实 当然，我这里是小成本，仅仅一个数据库服务器的情况，如果你要用多组服务器，或者其他什么增加成本的方式解决，那就当我没问

[猿小陆]

@m 0 物化视图快

[m 0]

引用 4 楼 sxq129601的回复:

可能我才疏学浅，视图就是SQL只是封装了一下，对效率没有半点提高

111同求，同询问。。。。

[Lonnglong]

可能我才疏学浅，视图就是SQL只是封装了一下，对效率没有半点提高

[lengIII]

视图仅仅是查询结果的整理吧，按道理说应该更慢一点。

[morliz子轩]

个人认为，查询的结果集，如果数据量是恒定的，且在5W以内，可以考虑用视图界定它。 再通过方法去调用它。(另一个要主要考虑：数据库服务器硬件性能，如果是专业级服务器可视情况而定，10W甚至更高） 但如果这个数据量变化起伏跌宕，不建议做成视图。直接用临时表取法

[难得自然萌]

引用 8 楼 吉普赛的歌 的回复:

对于报表来说， 关联比较多， 逻辑复杂， 数据量大， 这种情况只有临时表是最合适的。 但临时表， 最好也加一下索引， 便于提高效率。 至于视图中强制用索引， 有用处， 但对报表来说改善并不明显。 何况也普通sql也是可以指定索引的。 而且指定索引会带来一些问题， 比如索引的删除，修改就会造成原有查询出错， 所以不建议在查询写死索引。

吉普赛的歌说的很清楚了，逻辑复杂的临时表效率更高，视图可以理解为对多表关联的重复使用

[forumtom]

应该是临时表效率高

[洗凉]

投临时表一票

[netcup]

为什么不用存储过程调用呢？

[dotgame1]

经常使用超过百万条记录的表进行交叉查询，前期用视图指定索引，后期直接放弃，全部用临时表了。