设计应用程序的时候降低SQL语句复杂度的6个要点

设计应用程序的时候降低SQL语句复杂度的6个要点

（1）动态语句

一些应用为了实现客户端的灵活性，会根据用户的选择，动态拼出TSQL语句，发给SQL运行。

例如，在用户界面上列出各种条件，让用户根据自己的喜好，输入条件，进行组合查询。

这样在功能上来讲比较强大，但是在复杂度控制上就有可能会出问题。

如果用户选择的条件太多，或者根据条件返回的记录太多，就有可能会造成问题。

而有些能够过滤大量数据，或者在索引上的条件如果没有被选上，就有可能造成在大表上的table scan。

最好在程序里有动态语句复杂度的控制机制，限制选择的条件限制返回记录的数量

 

（2）表格联接的数量

为了支持复杂的业务逻辑，一个应用往往会有成百上千的表格，一些查询往往会联接十几张甚至几十张表。

应用设计的时候对这样的查询要很慎重。如果表格很大，十几张表做联接，肯定不会有好的性能。

如果应用是支持数据分析系统，那可能还好。如果应用是一个OLTP系统，这样的设计失败的风险可能会很大。

有时候可能需要降低数据库范式级别，多保存一些冗余数据列，以减少表格联接的数量

 

（3）视图和存储过程的深度

视图和存储过程能够抽象出一些业务逻辑，简化设计，是很推荐的做法。

但是如果在引用视图和存储过程时不加注意，视图套视图，存储过程嵌存储过程，最后嵌套上四五层，

那复杂度累积起来，可能会超出你想象。对SQL的优化，也是很严重的考验。所以在引用他们的时候，也要考虑累积的复杂度

 

（4）不必要的排序和计算

对一个大结果集做排序，或者求唯一值，都是比较昂贵的计算，会占用大量系统资源如果用户对结果集排序或唯一性的要求不高，

可以适当去掉这些计算

 

（5）超大结果集申请和返回

如果根据用户选择的过滤条件，SQL会返回十几万条记录，那应用层该如何处理？

如果一次性返回给应用层，那应用层要缓存和处理这么多记录，自己的性能会受到很大的挑战。

如果一次只取一部分记录，其他记录由SQL代为缓存（一般是应用服务器端游标），那不但会给SQL的内存使用带来负担，

而且容易产生阻塞问题。如果应用层处理得不好，甚至会产生内存泄漏的问题。

所以程序设计的时候，要确保应用只会申请合适的、有必要的结果集。例如一个用户在网页上查询他感兴趣的产品，

可能最多只会看前面的100个。如果你返回一万一个产品记录给他，除了暗示你产品多以外，对用户没有任何意义。

这时候在语句里设置一个top 100，可能是个合理的选择

 

 （6）用多个简单语句替代一个复杂语句

如果一个复杂的语句有很多张表要联接，要做很多计算，很多时候，要根据表和表的逻辑关系，

知道某一张表和另一张表如果先做联接，可能会过滤掉更多数据。

得到的小的结果集再做其他联接，会更快。类似的，有些计算可以先做，也可以后做，

人在了解了表格的逻辑之后会知道是先做好还是后做好。

可惜SQL作为一个计算机程序，在这方面没有人那么聪明。当语句太复杂的时候，他有可能看不出来了。

为了提高性能，对这种特别复杂的语句，可以把一句话拆成两句，甚至三句分步做完，中间结果集，可以以临时表的形式存放。

这样做对程序员来讲做了很多事，但是对SQL来讲，大大简化了复杂度。很多时候对性能也会有帮助