浅谈大数据量查询

        前两天开会，提到了大数据量查询较慢的问题。其实这个问题我们不止一次遇到了，今天简单谈谈对这个问题的一些小看法。

        首先，客户最长能忍受多长时间的等待呢？

        当然，不让用户等待是最好的，或者说不让用户觉得实在等待！最简单的比如loading图片、进度条等。其实，Ajax的异步通信也是为了不让用户感觉到在等待！

        那么如果非得说要让客户等待系统反应，这个时间到底是多少呢？以我个人观点，普通需求不可以超过3秒钟。假如你点击了一下查询按钮，前两秒钟没反应，客户可能会开始思考这是怎么回事，如果到第三秒钟还没出结果，客户会判定出问题了！当然，对于程序特殊需求如导入导出等除外。

        还有就是，遇到这样的问题，我们应该怎么办？

        大部分人的第一反应可定时程序代码是不是有问题。如果真的是代码逻辑有问题，这倒是好解决的了。但是事实往往不是这样的。

        事实上，出现这样的问题70%在sql语句上，20%出现在表设计上。对于出现在sql语句上的问题，一些常见的如表连接的使用、in关键词的使用等，大家可以一一检查。

        而如果真的是在表设计上出了问题，我们改怎么办？推倒重来？这是不可想象的一件事！因为这样的问题，大多是在软件后期才发现的。这就意味着大部分工作都完成了，才发现设计上导致出现这样的问题！

        很不幸，我们在之前的系统上就是设计上考虑不周，出现了查询较慢的问题。相对于这次会议上说的sql语句的问题，我们那次真的是一次恐怖的遭遇啊！

        简单的说，我们的问题是这样：构成视图的表太多！我记得构成这个视图的表在20张以上，而数据量大约在3万条。这样的情况，每次查询大概2-3秒的样子，算是勉强可以接受的。

        其实在后来，我们讨论的时候也说到过这个问题，当初的设计确实是有问题的！当初为了灵活性使用了大量中间表，其实没必要所有的地方都使用中间表，那样会减少很多表关系！

        我们现在的数据量是几万条，其实根本不能算是大数据量！sql server是完全可以轻松处理几十万条乃至百万条数据的。所以，出现几万条就很慢的时候，一定是有些地方没设计好。

        最后还想说，大数据量的测试，绝对不能等到最后测试。而是应该在设计阶段就要考虑，编码后马上测试，以便尽早发现尽早解决！