大数据读取时，页面超卡，什么原因？
最近遇到一个问题，一个页面在加载的时候打开很慢或者干脆打不开。

这个页面设计的数据量 百万条左右。

以前人查询的方式是直接 通过 表名 来查询的。

不知道改成 通过 视图 来做，能不能缓解这样的情况。

大数据量的时候，通过原表名 查询  和 视图 查询，哪个有 优势点？


------解决方案--------------------
首先慢的问题，lz还是从索引，使用的并发，还有io压力上来看。 

实际设计中，建议使用视图，毕竟不知道什么时候用户会说，我不想看3年前的数据，或者不想看XXX的数据。视图这个时候就可以发挥作用了。 

------解决方案--------------------
页面加的东西太多了啊，当然卡

你一个页面加载上百万给谁看啊
------解决方案--------------------
不知道改成 通过 视图 来做，能不能缓解这样的情况。
--> 不能.

大数据量的时候，通过原表名 查询  和 视图 查询，哪个有 优势点？
--> 没有可比性,关键分析执行计划和查看是否进程阻塞.

这张表存在一个高并发操作的问题，容易产生死锁。如何来解决高并发的问题？
--> 读取是加nolock选项.
------解决方案--------------------
区别：1、视图是已经编译好的sql语句。而表不是         2、视图没有实际的物理记录。而表有。      3、表是内容，视图是窗口      4、表只用物理空间而视图不占用物理空间，视图只是逻辑概念的存在，表可以及时四对它进行修改，但视图只能有创建的语句来修改      5、表是内模式，试图是外模式      6、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角度说，视图可以不给用户接触数据表，从而不知道表结构。      7、表属于全局模式中的表，是实表；视图属于局部模式的表，是虚表。       8、视图的建立和删除只影响视图本身，不影响对应的基本表。联系：视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻辑意义上建立的新关系
------解决方案--------------------
具体的你可以查看执行计划，看看有什么不同，那个效率更高些