如果有国际化需要，所有的字符存储与表示，均以utf-8编码，注意字符统计函数的区别。【说明：SELECT LENGTH("轻松工作")；返回为12；SELECT CHARACTER_LENGTH("轻松工作")； 返回为4；如果需要存储表情，那么选择utf8mb4来进行存储，注意它与utf-8编码的区别。】
TRUNCATE TABLE比DELETE速度快，且使用的系统和事务日志资源少，但TRUNCATE无事务且不触发trigger，有可能造成事故，故不建议在开发代码中使用此语句【说明：TRUNCATE TABLE在功能上与不带WHERE子句的DELETE语句相同】
(四) ORM映射在表查询中，一律不要使用*作为查询的字段列表，需要哪些字段必须明确写明【说明：1）增加查询分析器解析成本。2）增减字段容易与resultMap配置不一致。3）无用字段增加网络消耗，尤其是text类型的字段】
POJO类的布尔属性不能加is，而数据库字段必须加is_，要求在resultMap中进行字段与属性之间的映射。【说明：参见定义POJO类以及数据库字段定义规定，在<resultMap>中增加映射，是必须的。在MyBatis Generator生成的代码中，需要进行对应的修改】
不要用resultClass当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个POJO类与之对应【说明：配置映射关系，使字段与DO类解耦，方便维护。】
sql.xml配置参数使用：#{}，#param#不要使用${}此种方式容易出现SQL 注入
不允许直接拿HashMap与Hashtable作为查询结果集的输出【说明：resultClass=”Hashtable”，会置入字段名和属性值，但是值的类型不可控】
更新数据表记录时，必须同时更新记录对应的gmt_modified字段值为当前时间
不要写一个大而全的数据更新接口。传入为POJO类，不管是不是自己的目标更新字段，都进行update table set c1=value1,c2=value2,c3=value3;这是不对的。执行SQL时，不要更新无改动的字段，一是易出错；二是效率低；三是增加binlog存储
@Transactional事务不要滥用。事务会影响数据库的QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等
<isEqual>中的compareValue是与属性值对比的常量，一般是数字，表示相等时带上此条件；<isNotEmpty>表示不为空且不为null时执行；<isNotNull>表示不为null值时执行。
六、工程结构
分层异常处理规约
在DAO层，产生的异常类型有很多，无法用细粒度的异常进行catch，使用catch(Exception e)方式，并throw new DAOException(e)，不需要打印日志，因
为日志在Manager/Service层一定需要捕获并打印到日志文件中去，如果同台服务器再打日志，浪费性能和存储。在Service层出现异常时，必须记录出错日志到磁盘，尽可能带上参数信息，相当于保护案发现场。如果Manager层与Service同机部署，日志方式与DAO层处理一致，如果是单独部署，则采用与Service一致的处理方式。Web 层绝不应该继续往上抛异常，因为已经处于顶层，如果意识到这个异常将导致页面无法正常渲染，那么就应该直接跳转到友好错误页面，加上用户容易理解的错误提示信息。开放接口层要将异常处理成错误码和错误信息方式返回。
分层领域模型规约
DO（Data Object）：此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象
DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象
BO（Business Object）：业务对象，由Service层输出的封装业务逻辑的对象
AO（Application Object）：应用对象，在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高
VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象
Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用Map类来传输
二方库依赖
1）GroupID格式：com.{公司/BU }.业务线 [.子业务线]，最多4级。正例：com.taobao.jstorm或com.alibaba.dubbo.register
2）ArtifactID格式：产品线名-模块名。语义不重复不遗漏，先到中央仓库去查证一下。正例：dubbo-client / fastjson-api / jstorm-tool
3）Version：主版本号.次版本号.修订号。【1.主版本号：产品方向改变，或者大规模 API 不兼容，或者架构不兼容升级；2.次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的 API 不兼容修改；3.修订号：保持完全兼容性，修复 BUG、新增次要功能特性等】
说明：注意起始版本号必须为：1.0.0，而不是0.0.1，正式发布的类库必须先去中央仓库进行查证，使版本号有延续性，正式版本号不允许覆盖升级。如当前版本：1.3.3，那么下一个合理的版本号：1.3.4或1.4.0或2.0.0
底层基础技术框架、核心数据管理平台、或近硬件端系统谨慎引入第三方实现