如何优化大数据高并发量的系统的SQL语句提高效率

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化。为了获得稳定的执行性能，SQL语句越简单越好。对复杂的SQL语句，要设法对之进行简化提高它的解决效率。

489034603

当看到一个SQL语句带来了性能问题的时候，首先要看看它的执行计划。看看他是否走了你所期望的索引。物理读逻辑读是不是在合理的范围之内？对于这类的性能问题，可以追溯到表的设计阶段，例如，为 了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余，然而，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。下面我们来谈谈优化的技巧：

【1】表设计的优化

1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。

2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的。

3、对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。

4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。

5、字段顺序对存储效率也有不小的影响。在做表结构设计的时候，我们往往不会去考虑字段的摆放顺序。但是，实际上字段的摆放顺序对数据库操作的性能是有影响的。

6、针对各种类型的表来存储各种类型的数据

【2】 语句的查询优化

1、保证在实现功能的基础上，尽量减少对数据库的访问次数；

2、通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；

3、在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；

4、在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；

5、在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。

6、在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。

7、在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。

8、合理的使用临时表。例如表A 的 ID 字段有索引，并且这个表的数据有很多。这时候要查询这个ID 的最大值与最小值，如果能合理使用临时表，速度将大幅度提高！

9、多层的子查询需要进行简单化。

【3】建立高效的索引

创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储，一个表只允许有一个簇索引，因此，根据B树结构，可以理解添加任何一种索引均能提高按索引列查询的速度，但会降低插入、更新、删除操作的性能，尤其是当填充因子（Fill Factor）较大时。所以对索引较多的表进行频繁的插入、更新、删除操作，建表和索引时因设置较小的填充因子，以便在各数据页中留下较多的自由空间，减少页分割及重新组织的工作。据说大部分的数据库性能问题都可以采用索引技术得到解决。

【4】 强制查询转换

有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取！

489034603

【经验之谈】

在日常我们开发的系统中有很多的SQL 语句被写成N层嵌套，我们应该在了解了业务之后，将复杂的SQL 改成多个简单的语句逐步处理，再或者用with as 语法，这个可以解决不少的性能的问题。再者，很多朋友不会使用分析函数，认为它会带来一定的性能问题，其实这是错的。使用分析函数的查询，不但语法简洁，查询效率来看比自己拼得多层查询的效率要好很多。

以上为个人观点，供大家参考，因为每个公司的业务逻辑不同，所采用的方法也不尽相同，我们只能做的让它变的更好，在大数据领域没有最好。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。