没有

Mysql本来不支持视图的。但是在5.0以上的版本，支持了视图功能，但是可惜的是不提供物化视图，但是这也难不住咱们，自己动手丰衣足食。

在一次sql优化中，一个select count(*)语句因数据量实在太大，已经无法从简单的索引进行优化了，在同事的推荐下考虑到了物化视图

物化视图是相对于视图而言的，但是两者实际上并没有什么关系就如java/javaScript一样

首先mysql的视图不是一种物化视图，他相当于一个虚拟表，本身并不存储数据，当sql在操作视图时所有数据都是从其他表中查询出来的。带来的问题是使用视图并不能将常用数据分离出来，优化查询速度，且操作视图的很多命令和普通标一样，这会导致在业务中无法通过sql区分表和视图，使代码变得复杂。

视图是简化设计，清晰编码的东西，他并不是提高性能的，他的存在只会降低性能（如一个视图7个表关联，另一个视图8个表，程序员不知道，觉得很方便，把两个视图关联再做一个视图，那就惨了），他的存在主要在设计上的方便性

实现视图的方法有两种，分别为合并算法和临时表算法，合并算法是指查询视图是将视图定义的sql合并到查询sql中，比如create view v1 as select * from user where sex = m;当我们要查询视图时，mysql会将select id,name from v1转化成select id,name from user where sex= m; 临时表算法是将视图查出来的数据保存到一个临时表中，查询的时候查这个临时表。不管是合并算法和临时算法，都会给数据库带来额外的开销，且如果使用临时表后会使mysql的优化变得很困难，比如索引，而且视图还引入了一些其他的问题，是的其背后的逻辑非常复杂。

当然，视图在某些情况下还是可以帮助提升性能的，单视图的性能很难预测，且在mysql的优化器中，视图的代码执行路径也完全不同，无法直观预测其性能。

物化视图是是查询结果的预运算，物化视图的结果一般存储于表中。物化视图用于需要对查询立即做出响应，而又需要耗费长时间获得结果。物化视图必须能快速更新。它去介于对更新频率和内容的准确性的要求。一般来说，物化视图能够在一定时间内及时更新。