一、後端接口
- 禁止使用遞歸；原因：每次遞歸調用時會向棧中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優化的一些建議，由於後期很少寫業務代碼了，就懶得更新了，歡迎補充…