Java后端接口、Mysql优化建议与规范

一、后端接口

• 禁止使用递归；原因：每次递归调用时会向栈中push当前方法的运行状态（现场），而Java栈内存的使用超过限制的大小时，程序会出现栈异常；
• 避免层级嵌套循环；
• 注意方法、类文件中的代码量，适度分离；
• 使用基本类型定义变量时，千万注意该变量值可能为null的情况，此时建议使用对应的包装类来定义变量；
• 避免在同一接口中过多的访问数据库，建议次数控制在3次以内；
• 避免过多使用static变量；原因：静态变量和类的生命周期同步；
• 尽量采用lazy loading的策略，即在需要的时候才开始创建变量和对象等；
• 将一些需要变动的配置或文案写在属性文件中；
• 后端接口需要提供必要的校验，不要过于依赖前端校验；
• SQL语句较长时建议采用Provider拼接，拼接查询Sql时加上” where 1 = 1 “；
• 提倡异常封装，提高代码可读性和可维护性等；
• 避免使用硬编码，多使用final定义常变量，提高可读性；

2、SQL优化

• 尽量使用简单的SQL，避免多表查询以及在SQL中处理复杂的逻辑；
• 避免使用SQL语句排序，尽量在程序中进行排序；
• 查询时避免全表扫描，适度增加索引；
• 设计表结构时：id、created、updated、version NOT NULL；id AUTO_INCREMENT
• 在查询时不要对所查询列使用函数或者运算，否则索引无法使用到；
• 尽量使用GROUP BY替换DISTINCT；
• JOIN时使用小结果集驱动大结果集；
• 建议使用”临时表”暂存中间结果；
• 模糊查询(LIKE)时避免在关键词前使用”%”（如：LIKE '%小分期'），否则查询必然是全表扫描；
• 对查询进行优化，应尽量避免全表扫描，首先应考虑在where 及 order by涉及的列上建立索引。
• 应尽量避免在 where 子句中使用!=或<>操作符、函数操作、表达式（如：num/2）以及null值判断，否则将引擎放弃使用索引而进行全表扫描。
• 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
  select id from t where num=10 or num=20
  可以这样查询：
  select id from t where num=10
union all
select id from t where num=20
• in 、 not in 、or 也要慎用，否则条件超过一定数量会导致索引失效(特别注意：严格禁止in后面使用子查询)，如：
  select id from t where num in(1,2,3)
  对于连续的数值，能用 between 就不要用 in 了：
  select id from t where num between 1 and 3
• 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引。一个表的索引数最好不要超过6个。
• 任何地方都要慎重使用 select * from t取出所有列 ，不要返回用不到的任何字段。
• 适当将复杂查询切分为若干个单表查询或简易查询。如将关联查询分解为若干个单表查询。
• 老老实实按照规范写SQL，比如字符串一律该加引号就加引号。WHERE username = 1380000000和WHERE username = '1380000000'是不同的。后者能正确使用索引，前者不能。
• 数据库表有version字段的，应当强制不为空。因为baseDao每次更新记录都会在这个字段加1，为空的话会出现异常。
• where/group by/order by 的条件里，禁止给索引列套上函数，会让索引失效。例如：WHERE date(created) > '2017-01-01' 这样的写法绝对禁止。

写在最后：以上为实习期总结的后端接口、sql优化的一些建议，由于后期很少写业务代码了，就懒得更新了，欢迎补充…