Java干货SQL优化？入门新手，你也可以做到！

针对一个刚入门的开发人员来说，不要整天谈什么框架什么架构，先把基础打牢。在学习和工作过程中注重自己的总结和积累，养成好的编程习惯，注重在开发过程中的细节，往往在实际开发过程中由于细节和严谨性不到位可能引发灾难性的后果。

今天整理一下在基于关系型数据库开发sql编程中注意的一些细节，这些细节不是有多高的难度，更多强调的是一个开发人员要有一种严谨和良好的编程习惯，在生产环境中不要为了图方便省事走捷径。

大原则

如果项目组已经制定了非常详细明确的规范，你都得抛弃你以前自己的一套规范无条件的去遵循内部的开发规范，除非你的建议改变了你们项目组的规范。其中这些规范包括编程中的代码命名、注释、格式、日志、异常、目录结构层次、sql编写等规约。

关于优化方面，针对项目中的实际问题，一定要结合实际的项目环境进行实际的测试对比进行衡量，灵活把握度的控制，直接的优化效果胜于一切纸上谈兵。

细节举例

01

针对数据量大的表保持头脑清醒写语句再结合实际测试对比，不止注重结果更要注重效率（大原则）。

02

能用where优先过滤掉大数据量的就优先过滤掉大数据集（大原则）。

03

减少约束的设计，尽量把约束都交给服务层让代码去控制，减轻数据库服务器的压力（大原则）。

04

非必要切忌不要来笛卡尔积，太过于暴力和恐怖。

05

在sql查询中能优先使用内置函数时，尽量优先用数据库自带的内置函数，相信产品内部封装绝对优于自己的封装。

06

select查询语句中尽量避免*查询所有，根据实际业务需要出发需要多少字段就取多少字段。

举例：如果一张表有60个字段，其中需要的仅是其中两个字段，如果用*获取所有无论是对数据库列的查询还是数据在传输过程中的开销都是对时间和资源的浪费。

07

在能满足业务数据基础上尽量减少对数据库的连接，在每次与数据库连接后在数据库内部对语句执行计划、索引、约束等资源的调取都是很耗费资源的，能一次性一条sql语句能搞定的尽量一次性搞定。

08

where字句位置定位，在一条sql解析顺序中，where都是发生在多表连接之后进行执行，如果where语句条件可以提前过滤掉大数据量可以将where字句提前到发生连接之前。

09

在做连接表的查询时，结合业务选择适当基础表进行连接。

10

在group by的having语句尽量先用where语句优先过滤掉，having语句是在group by的结果基础上进行过滤，如果where能优先对数据过滤效率会有所提升。

11

索引是提高查询的利器，但是也是一把双刃剑，如果用不好反伤就可以秒杀自己，所以一定要知道索引的基础原理，什么场景下适合用，在写sql中如何去命中它，列举索引不会被命中的场合：

有的系统由于经历了二次开发、三次开发，还可能中间业务进行了多次变更，开发人员的更换导致有很多索引已经是没有用的索引了，一定要监控数据库查看索引使用情况，如果找到没用到的索引一定要进行清理和优化操作；

索引列上加 is null 或 is not null；

在条件查询中基于索引列进行了函数运算操作后不会命中，例如to_char、to_number运算函数；

隐式转换也会导致索引失效，如id=100，如果id是字符型，会将其转换为to_number(id)=5，所以不要以字符格式写作数字，也不要以数字格式写作字符；

!=、not、可能会导致索引失效；

在分页中有人经常用1=1会导致索引失效；

模糊匹配like会导致索不会被命中 %hello不会被命中，hello%会被命中；

运算符+、||拼接符停用了索引；

12

尽量减少distinct、union、order by操作，因为这类型操作需要在数据库中对数据进行排序运算非常消耗资源。

13

union all效率要高于union，如果明确没有重复数据的情况下请用union all，因为union会主动去重。

14

减少对or、in关键字的运用，用exist或

union替换or或in的运用。

15

存储过程用还是不用完全取决于项目的规约还有项目环境等条件进行综合决策，这是一个度的把握，是把业务的处理拦截在上层服务层处理还是放在数据库服务器综合进行处理各有利弊。

16

低级错误：使用原生JDBC不关闭资源，尽量执行事务commit或rollback操作，释放数据库服务器内存资源。