最近做了个项目，完工之后发现项目某个页面的查询速度相当慢，最快查询20秒出结果，最慢查询40秒出结果，这对于客户的体验感来说，应该是相当差的，在不优化数据库部署的情况下，只能去优化查询的方式

在不使用遍历查询，而使用视图查询的情况下，很显然，视图的查询是更快的，但是这个项目其实已经用上了视图查询，那就只能去优化视图了，首先，可以知道的是，在视图的查询中，需要查出来的字段越少，速度可能就会越快，当然，如果你只是用于统计计数，那毫无疑问，可以选择count(1)去进行查询，它的速度应该是很难在继续往后优化了（在我目前的认知里，只针对现在的我），但是这个项目它需要的不是统计计数，而是需要数据的，那么就只能去选择减少字段，但是这个视图应用的范围特别的广，手机端，pc端都有使用，如果单对这个页面进行优化，减少字段，很显然不可行，那么就只能再建一个视图，专门针对这个页面的视图，从而去取只有这个页面需要的字段，这种方法可行，但是由于这个项目是别人先做的，我本次做是加新功能，很多字段都要去查，能不能删，需不需要，很显然，也是一件费时费力的事情。

之前视图的源代码是这样的

筛查条件是这样的

很显然，VisitDate，UserID都是a表中的数据，在这种情况下，整个查询速度大概需要20-40秒
后来我将视图改成了这样

将a表中的VisitDate，UserID改到了r表中，那么筛选条件中的这两个字段也就是对应到r表中的数据，这里需要注意的是我这两张表中，这两个字段的数据是一致的，a表和r表数据条数是一致的，r表是a表的关联数据表，所以可以这样做，当这样做之后，查询速度从20-40秒，变成了1-2秒

因为这种现象我也是第一次遇到，遇到就是学到嘛，猜测大概率是因为left join的原因，因为在这个视图中主要是根据ReportRecord表的数据来的，在对r表的数据进行筛选之后，被筛查出去的数据的这部分，后面的表就都可以不用查，主要应该是这个原因提升了这个查询速度，当然还猜测因为a表用了个INNER JOIN导致查询速度不快，不然应该速度差距也不会这么离谱。

根据这个表象，可以得出，以后在传出字段的时候，尽量往left左边的表的字段传出，在多表数据一样的情况下，这样筛查也会去筛查左边表里面的数据，会加快查询速度，程序这东西，真的还是要多学，才能扩展开来自己的视野，很显然这部分就在我的盲区，得加油。