一、后端接口

禁止使用递归；原因：每次递归调用时会向栈中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) > ‘2021-01-01’ 这样的写法绝对禁止。