该使用双参数 decode(string source, string encode)。接口提供方既然明确是过时接口， 那么有义务同时提供新的接口；作为调用方来说，有义务去考证过时方法的新实现是什么。

5. 【强制】object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用

6. 关于基本数据类型与包装数据类型的使用标准如下：

1） 【强制】所有的 pojo 类属性必须使用包装数据类型。

2） 【强制】rpc 方法的返回值和参数必须使用包装数据类型。

3） 【推荐】所有的局部变量使用基本数据类型。

说明：pojo 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何

npe 问题，或者入库检查，都由使用者来保证。

正例：数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 npe 风险。反例：比如显示成交总额涨跌情况，即正负 x%，x 为基本数据类型，调用的 rpc 服务，调用不成功时，返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null 值，能够表示额外的信息，如：远程调用失败，异常退出。

7. 【强制】定义 do/dto/vo 等 pojo 类时，不要设定任何属性默认值。

反例：pojo 类的 gmtcreate 默认值为 new date()，但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。

8. 【强制】序列化类新增属性时，请不要修改 serialversionuid 字段，避免反序列失败；如果完全不兼容升级，避免反序列化混乱，那么请修改 serialversionuid 值。

说明：注意 serialversionuid 不一致会抛出序列化运行时异常。

9. 【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。

说明：在方法执行抛出异常时，可以直接调用 pojo 的 tostring()方法打印其属性值，便于排查问题。

11. 【强制】禁止在 pojo 类中，同时存在对应属性 xxx 的 isxxx()和 getxxx()方法。说明：框架在调用属性 xxx 的提取方法时，并不能确定哪个方法一定是被优先调用到。

12. 【推荐】使用索引访问用 string 的 split 方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛 indexoutofboundsexception 的风险。

13. 【推荐】当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起， 便于阅读，此条规则优先于第 16 条规则。

说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为承载的信息价值较低，所有 service 和 dao 的 getter/setter 方法放在类体最后。

15. 【推荐】setter 方法中，参数名称与类成员变量名称一致，this.成员名 = 参数名。在

getter/setter 方法中，不要增加业务逻辑，增加排查问题的难度。反例：

16. 【推荐】循环体内，字符串的连接方式，使用 stringbuilder 的 append 方法进行扩展。说明：下例中，反编译出的字节码文件显示每次循环都会 new 出一个 stringbuilder 对象， 然后进行 append 操作，最后通过 tostring 方法返回 string 对象，造成内存资源浪费。 反例：

17. 【推荐】final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：

1） 不允许被继承的类，如：string 类。

2） 不允许修改引用的域对象。

3） 不允许被重写的方法，如：pojo 类的setter 方法。

4） 不允许运行过程中重新赋值的局部变量。

5） 避免上下文重复使用一个变量，使用 final 描述可以强制重新定义一个变量，方便更好地进行重构。

说明：对象的 clone 方法默认是浅拷贝，若想实现深拷贝需要重写 clone 方法实现域对象的深度遍历式拷贝。

19. 【推荐】类成员与方法访问控制从严：

1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。

4） 类非 static 成员变量并且仅在本类使用，必须是 private。

5） 类 static 成员变量如果仅在本类使用，必须是 private。

7） 类成员方法只供类内部调用，必须是 private。

8） 类成员方法只对继承类公开，那么限制为 protected。

说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。思考：如果是一个 private 的方法，想删除就删除，可是一个 public 的 service 成员方法或成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作用域太大，无限制的到处跑，那么你会担心的。

2） 因为 set 存储的是不重复的对象，依据 hashcode 和 equals 进行判断，所以 set 存储的对象必须重写这两个方法。

2. 【强制】使用集合转数组的方法，必须使用集合的 toarray(t[] array)，传入的是类型完全一样的数组，大小就是 list.size()。

说明：使用 toarray 带参方法，入参分配的数组空间不够大时，toarray 方法内部将重新分配内存空间，并返回新数组地址；如果数组元素个数大于实际所需，下标为[ list.size() ] 的数组元素将被置为 null，其它数组元素保持原值，因此最好将方法入参数组大小定义与集合元素个数一致。

反例：直接使用 toarray 无参方法存在问题，此方法返回值只能是 object[]类，若强转其它类型数组将出现 classcastexception 错误。

说明：aslist 的返回对象是一个 arrays 内部类，并没有实现集合的修改方法。arrays.aslist体现的是适配器模式，只是转换接口，后台的数据仍是数组。

方式，如果并发操作，需要对 iterator 对象加锁。正例：

说明：以上代码的执行结果肯定会出乎大家的意料，那么试一下把“1”换成“2”，会是同样的结果吗？

1） x，y 的比较结果和 y，x 的比较结果相反。

3） x=y，则x，z 比较结果和 y，z 比较结果相同。

反例：下例中没有处理相等的情况，实际使用中可能会出现异常：

6. 【推荐】集合泛型定义时，在 jdk7 及以上，使用 diamond 语法或全省略。说明：菱形泛型，即 diamond，直接使用<>来指代前边已经指定的类型。

7. 【推荐】集合初始化时，指定集合初始值大小。

factor）默认为 0.75，如果暂时无法确定初始值大小，请设置为 16（即默认值）。

反例：hashmap 需要放置 1024 个元素，由于没有设置容量初始大小，随着元素不断增加，容量 7 次被迫扩大，resize 需要重建 hash 表，严重影响性能。

9. 【推荐】高度注意 map 类集合 k/v 能不能存储 null 值的情况，如下表格：

10. 【参考】合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。

11. 【参考】利用 set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 list 的

contains 方法进行遍历、对比、去重操作。

1. 【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。说明：资源驱动类、工具类、单例工厂类都需要注意。

2. 【推荐】创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。正例：

3. 【推荐】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

说明：使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

4. 【推荐】线程池不允许使用 executors 去创建，而是通过 threadpoolexecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

说明：executors 返回的线程池对象的弊端如下：

允许的请求队列长度为 integer.max_value，可能会堆积大量的请求，从而导致 oom。

允许的创建线程数量为 integer.max_value，可能会创建大量的线程，从而导致 oom。

正例：注意线程安全，使用 dateutils。亦推荐如下处理：

6. 【推荐】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。

说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 rpc 方法。

7. 【推荐】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。

说明：如果每次访问冲突概率小于 20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于 3 次。

8. 【强制】多线程并行处理定时任务时，timer 运行多个 timetask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 scheduledexecutorservice 则没有这个问题。

9. 【强制】禁止在循环语句中进行数据库增删改查操作，高并发时，会耗尽数据库连接池资源，如果遇到耗时的操作，会导致连接占用时间过长而一直得不到释放，会造成其他请求获取不到连接的情况。循环插入、更新、删除数据库可以使用jdbc batch update进行操作，循环查询数据库可以一次查询满足条件的所有数据，然后再进行筛选。

10. 【推荐】使用 countdownlatch 进行异步转同步操作，每个线程退出前必须调用 countdown 方法，线程执行代码注意 catch 异常，确保 countdown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果。

说明：注意，子线程抛出异常堆栈，不能在主线程 try-catch 到。

11. 【推荐】避免 random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一

seed 导致的性能下降。

正例：在 jdk7 之后，可以直接使用 api threadlocalrandom，而在 jdk7 之前，需要编码保证每个线程持有一个实例。

性能更好（减少乐观锁的重试次数）。

13. 【参考】 hashmap 在容量不够进行 resize 时由于高并发可能出现死链，导致 cpu 飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险。

14. 【参考】threadlocal 无法解决共享对象的更新问题，threadlocal 对象建议使用 static 修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。

1. 【强制】在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使空代码。

3. 【推荐】表达异常的分支时，少用 if-else 方式，这种方式可以改写成：

说明：如果非得使用 if()…else if()…else…方式表达逻辑，【强制】避免后续代码维护困难，请勿超过 3 层。

正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现， 其中卫语句示例如下：

4. 【推荐】除常用方法（如 getxxx/isxxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

说明：很多 if 语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？

5. 【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的 try-catch 操作（这个 try-catch 是否可以移至循环体外）。

6. 【推荐】避免采用取反逻辑运算符。

说明：取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。正例：使用 if (x < 628) 来表达 x 小于 628。

7. 【参考】下列情形，需要进行参数校验：

1） 调用频次低的方法。

2） 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。

3） 需要极高稳定性和可用性的方法。

4） 对外提供的开放接口，不管是 rpc/api/http 接口。

8. 【参考】下列情形，不需要进行参数校验：

1） 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。

2） 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般 dao 层与 service 层都在同一个应用中，部署在同一台服务器中，所以 dao 的参数校验，可以省略。

3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

1. 【强制】类、类属性、类方法的注释必须使用 javadoc 规范，使用/**内容*/格式，不得使用

说明：在 ide 编辑窗口中，javadoc 方式会提示相关注释，生成 javadoc 可以正确输出相应注释；在 ide 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。

2. 【强制】所有的抽象方法（包括接口中的方法）必须要用 javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。

说明：对子类的实现要求，或者调用注意事项，请一并说明。

3. 【强制】所有的类都必须添加创建者和创建日期。

4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。

5. 【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。

6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。

反例：“tcp 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。

7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。

说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后， 就失去了导航的意义。

8. 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。

说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。

9. 【参考】对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。

10. 【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

方法名 put，加上两个有意义的变量名 elephant 和 fridge，已经说明了这是在干什么，语

义清晰的代码不需要额外的注释。

11. 【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描， 经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。 1） 待办事宜（todo）:（ 标记人，标记时间，[预计处理时间]）

表示需要实现，但目前还未实现的功能。这实际上是一个 javadoc 的标签，目前的 javadoc

还没有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个 javadoc 标签）。

2） 错误，不能工作（fixme）:（标记人，标记时间，[预计处理时间]）

在注释中用 fixme 标记某代码是错误的，而且不能工作，需要及时纠正的情况。

1. 【强制】velocity 调用 pojo 类的属性时，建议直接使用属性名取值即可，模板引擎会自动按规范调用 pojo 的 getxxx()，如果是 boolean 基本数据类型变量（boolean 命名不需要加 is 前缀），会自动调用 isxxx()方法。

说明：注意如果是 boolean 包装类对象，优先调用 getxxx()的方法。

2. 【强制】注意 math.random() 这个方法返回是 double 类型，注意取值的范围 0≤x<1（能够取到零值，注意除零异常），如果想获取整数类型的随机数，不要将 x 放大 10 的若干倍然后取整，直接使用 random 对象的 nextint 或者 nextlong 方法。

4. 【推荐】任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。

5. 【推荐】及时清理不再使用的代码段或配置信息。

说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。

正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。

1. 【强制】java 类库中定义的可以通过预检查方式规避的 runtimeexception 异常不应该通过

2. 【强制】异常不要用来做流程控制，条件控制。

说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式要低很多。

3. 【强制】catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。

说明：对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。

正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于简单，在程序上作出分门别类的判断，并提示给用户。

4. 【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。

5. 【强制】有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回滚事务。

8. 【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。

9. 【推荐】方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。

说明：本手册明确防止 npe 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回

10. 【推荐】防止 npe，是程序员的基本修养，注意 npe 产生的场景：

2） 数据库的查询结果可能为 null。

3） 集合里的元素即使 isnotempty，取出的数据元素也可能为 null。

4） 远程调用返回对象时，一律要求进行空指针判断，防止 npe。

5） 对于 session 中获取的数据，建议 npe 检查，避免空指针。

12. 【参考】对于公司外的 http/api 开放接口必须使用“错误码”；而应用内部推荐异常抛出； 跨应用间 rpc 调用优先考虑使用 result 方式，封装 issuccess()方法、“错误码”、“错误简短信息”。

说明：关于 rpc 方法返回方式使用 result 方式的理由：

1） 使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。

2） 如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。

说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。

正例：一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：

1. 【强制】应用中不可直接使用日志系统（log4j、logback）中的 api，而应依赖使用日志框架

slf4j 中的 api，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

2. 【强制】对 trace/debug/info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。

正例：（条件）建设采用如下方式

4. 【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。

5. 【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。

说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？

6. 【推荐】可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。如非必要，请不要在此场景打出 error 级别，避免频繁报警。

说明：注意日志输出的级别，error 级别只记录系统逻辑出错、异常或者重要的错误信息。

1. 【强制】用户输入的 sql 参数严格使用参数绑定或者 metadata 字段值限定，防止 sql 注入， 禁止字符串拼接 sql 访问数据库。

2. 【强制】数据库连接字符串不应当在应用程序中硬编码。连接字符串应当存储在一个可信服务器的独立配置文件中，必要时，账户和密码字段需要加密。

3. 【推荐】当应用程序访问数据库时，应使用尽可能最低的权限。

1. 【强制】关闭服务器中文件上传目录的运行权限，防止或限制上传任意可能被 web服务器解析的文件。

2. 【推荐】将 web服务器、进程和服务的账户限制为尽可能低的权限。

3. 【推荐】为存储在服务器中的敏感信息提供恰当的访问控制。这包括缓存的数据、临时文件以及只允许特定系统用户访问的数据。

1. 【强制】用户请求传入的任何参数必须做有效性验证。说明：忽略参数校验可能导致：

l 正则输入源串拒绝服务 redos

说明：java 代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题， 但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。

2. 【强制】禁止向 html 页面输出未经安全过滤或未正确转义的用户数据。

3. 【强制】表单、ajax 提交必须执行 csrf 安全验证。

csrf 漏洞的应用/网站，攻击者可以事先构造好 url，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。

4. 【推荐】为包含敏感信息或功能、且连接到外部系统的连接使用 tls。

5. 【强制】不要在 http get请求参数中包含敏感信息。

6. 【强制】禁止表单中的自动填充功能，因为表单中可能包含敏感信息，包括身份验证信息。

7. 【强制】禁止客户端缓存网页，因为可能包含敏感信息。“cache-control: no-store”，可以和 http报头控制“pragma: no-cache”一起使用，该控制不是非常有效，但是与 http/1.0向后兼容。

8. 【推荐】为防范对随机数据的猜测攻击，应当使用加密模块中已验证的随机数生成器生成所有的随机数、随机文件名、随机 guid和随机字符串。

9. 【强制】不要在错误响应中泄露敏感信息，包括：系统的详细信息、会话标识符或者帐号信息。

10. 【推荐】不要在日志中保存敏感信息，包括：不必要的系统详细信息、会话标识符或密码。

11. 【强制】限制只有授权的用户才能访问受保护的 url。

12. 【强制】不要在 url、错误信息或日志中暴露会话标识符。会话标识符应当只出现在 http cookie头信息中。比如，不要将会话标识符以 get 参数进行传递。

13. 【推荐】如果任何潜在的 危险字符 必须被作为输入，请确保您执行了额外的控制，比如：输出编码、特定的安全 api、以及在应用程序中使用的原因。部分常见的危险字符包括：< > ” ‘ % ( ) & + \ \’ \” 。

1. 【推荐】为所有要求身份验证的访问内容和所有其他的敏感信息提供 tls连接

2. 【强制】在身份验证的时候，如果连接从 http变为 https，则生成一个新的会话标识符。在应用程序中，推荐持续使用 https，而非在 http和 https之间转换。

3. 【强制】所有的身份验证过程必须在可信系统（比如：服务器）上执行，身份验证的失败提示信息应当避免过于明确。比如：可以使用“用户名和/或密码错误”，而不要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致。

1. 【强制】表名必须以t_开头，如：t_user，函数以f_开头，存储过程已p_开头，视图以v_开头。

2. 【强制】字段名按照不同的数据类型进行命名，字符、文本类型以c_开头，如：c_user_name,整型（包含int,tinyint,bigint）、数字类型都统一以n_开头、时间类型用长时间格式进行存储，也以n_开头，double数据类型以d_开头，float数据类型以f_开头。

3. 【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。说明：mysql 在 windows 下不区分大小写，但在 linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。

4. 【强制】表名不使用复数名词。

说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 do 类名也是单数形式，符合表达习惯。

7. 【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

8. 【推荐】库名与应用名称尽量一致。

9. 【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

10. 【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循： 1）不是频繁修改的字段。

正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。

11. 【推荐】单表行数超过 500 万行或者单表容量超过 2gb，才推荐进行分库分表。

说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

12. 【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。

正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。

1. 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。

说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

2. 【强制】超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时， 保证被关联的字段需要有索引。

说明：即使双表 join 也要注意表索引、sql 性能。

3. 【推荐】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。

4. 【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。正例：where a=? and b=? order by c; 索引：a_b_c

反例：索引中有范围查找，那么索引有序性无法利用，如：where a>10 order by b; 索引

5. 【推荐】利用覆盖索引来进行查询操作，避免回表。

说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。

正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain 的结果，extra 列会出现：using index。

6. 【推荐】利用延迟关联或者子查询优化超多分页场景。

n 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 sql 改写。

正例：先快速定位需要获取的 id 段，然后再关联：

7. 【推荐】sql 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts

1） consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。

3） range 对索引进行范围检索。

反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全表扫描是小巫见大巫。

8. 【推荐】建组合索引的时候，区分度最高的在最左边。

说明：存在非等号和等号混合时，在建索引时，请把等号条件的列前置。如：where c>? and

d=? 那么即使 c 的区分度更高，也必须把 d 放在索引的最前列，即索引 idx_d_c。

9. 【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。

10. 【参考】创建索引时避免有如下极端误解：

1） 宁滥勿缺。认为一个查询就需要建一个索引。

2） 宁缺勿滥。认为索引会消耗空间、严重拖慢更新和新增速度。

3） 抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。

4. 【强制】使用 isnull()来判断是否为 null 值。说明：null 与任何值的直接比较都为 null。

5. 【强制】在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。

6. 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明：以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。

7. 【推荐】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

8. 【推荐】数据订正（特别是删除、修改记录操作）时，要先 select，避免出现误删除，确认无误才能执行更新语句。

9. 【推荐】in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在 1000 个之内。

10. 【参考】如果有国际化需要，所有的字符存储与表示，均以 utf-8 编码，注意字符统计函数的区别。

如果需要存储表情，那么选择 utf8mb4 来进行存储，注意它与 utf-8 编码的区别。

无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句。说明：truncate table 在功能上与不带 where 子句的 delete 语句相同