# woniu_doctor_admin
**Repository Path**: beansxdj/woniu_doctor_admin
## Basic Information
- **Project Name**: woniu_doctor_admin
- **Description**: 这仓库存放后端代码
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-10-13
- **Last Updated**: 2023-03-22
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# WoniuDoctor
## 介绍
蜗牛学院第三阶段开发项目,**蜗牛医生**，小组开发者必须遵守以下开发规范，在仓库创建自己的分支，每个人推送代码仅允许push到自己的分支，
严禁push到master，代码日更，记得完成下列附属文件：
- Debug日志
- Mysql日志
- 代码进度日志
## 版本管理规范
依赖版本
## Git Commit代码提交规范
git commit -m "提交注释"
### 格式说明
### 主要type
feat: 增加新功能
fix: 修复bug
### 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用,重构（即不是新增功能，也不是修改bug的代码变动）
revert: 执行git revert打印的message
### 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
## 分支管理规范
远程仓库只允许出现五种类型的分支：
- **主分支**：项目的主要分支也就是master分支。用于正式发布，该分支禁止任何人直接提交，提交合并请求由对应项目主管人员确认合并。
- **开发分支**：项目的开发迭代分支，用于开发发布，常规开发任务的代码直接提交至该分支或者由临时分支合并至该分支。
- **测试分支**：项目的测试迭代分支，用户测试发布，该分支禁止任何人直接提交，提交合并请求由对应项目主管人员确认合并。
- **归档分支**：项目的里程碑版本保留分支，由测试负责人、项目负责人、产品负责人直接定义版本，从测试分支归档出新分支。
- **临时分支**：由项目的开发人员建立的临时分支，禁止交叉提交，谁建立的分支便由谁负责管理，用于合并至开发分支，合并完成之后禁止新提交应当立刻删除。
#### 主分支
主分支全局仓库唯一，分支名称固定为**master**，任何对主分支的直接提交定性为严重违规行为，需要尝试对主分支进行合并应当由对应仓库的开发负责人提交合并请求并由上级负责人通过合并实现对主分支的变更。
#### 开发分支
开发分支全局仓库唯一，分支名称固定为**devLoop**，开发人员允许对该分支直接提交，任何向开发分支提交的代码在提交之前应当保证能够正常通过编译、部署并运行，无法部署的提交应当立刻修复并重新提交。开发分支部署的代码应当由开发人员完成所有的单元测试，全部通过之后再向测试分支提交。
#### 测试分支
测试分支全局仓库唯一，分支名称固定为**testLooop**，禁止直接对该分支提交，测试分支应当由开发分支提交合并请求而来，由开发人员提交合并请求，由主要开发人员通过合并请求实现测试部署。小型项目、中间件研发可以酌情省略测试分支，由开发分支部署交于测试进行质量校验，大型项目或产品必须保证有测试分支。
#### 归档分支
归档分支全局仓管可以具备多个，直接由测试分支或主分支派生，除特殊情况下禁止任何提交行为，归档分支名称格式为**release-版本号**（如：`release-1.2.0`），分支由对应项目的开发主要负责人再与测试负责人沟通之后创建，已经后续无论是BUG、还是功能性问题都不应当项归档分支提交。
#### 临时分支
临时分支全局仓库可以具备多个，临时分支名称格式为**tem-开发者-创建时间**（如：`tem-tangyuecan-20200724`），由开发人员自行创建，临时分支的提交进制交叉提交，只允许分支创建者提交，临时分支只能合并到开发分支一旦完成合并之后应当立即删除，可以直接本地合并之后向开发分支提交或者提交合并请求由开发负责人进行合并，临时分支的生命周期原则上不超过三个工作日。临时分支主要用于无法在短时间之内完成的开发工作，或者整合至开发分支之后无法运行情况，这样考虑之下才有临时分支的概念。
#### 提交描述
所以代码的提交、合并都应该通过文字目前描述出改此提交、合并的目的如下面几种：
- `修复问题：#xxxx`（禅道BUG的ID或者ISSUE）
- `修复问题：xxxx`（BUG的名称）
- `完成功能：#xxxx`（禅道的任务ID）
- `完成功能：xxxxx`（功能的名称）
任何无意义或者具体目的的提交禁止同步至远程仓库，包括远程临时分支（禁止commit）
## Java中的命名规范
| 类型 | 约束 | 例 |
| :----- | :----------------------------------------------------------- | :--------------------------------------------: |
| 项目名 | 全部小写，多个单词用中划线分隔‘-’ | spring-cloud |
| 包名 | 全部小写 | com.alibaba.fastjson |
| 类名 | 单词首字母大写 | Feature, ParserConfig,DefaultFieldDeserializer |
| 变量名 | 首字母小写，多个单词组成时，除首个单词，其他单词首字母都要大写 | password, userName |
| 常量名 | 全部大写，多个单词，用'_'分隔 | CACHE_EXPIRED_TIME |
| 方法 | 同变量 | read(), readObject(), getById() |
### 包命名
| 前缀名 | 例 | 含义 |
| :-------------- | :----------------------------- | :----------------------------------------------------------: |
| indi（或onem ） | indi.发起者名.项目名.模块名.…… | 个体项目，指个人发起，但非自己独自完成的项目，可公开或私有项目，copyright主要属于发起者。 |
| pers | pers.个人名.项目名.模块名.…… | 个人项目，指个人发起，独自完成，可分享的项目，copyright主要属于个人 |
| priv | priv.个人名.项目名.模块名.…… | 私有项目，指个人发起，独自完成，非公开的私人使用的项目，copyright属于个人。 |
| team | team.团队名.项目名.模块名.…… | 团队项目，指由团队发起，并由该团队开发的项目，copyright属于该团队所有 |
| 顶级域名 | com.公司名.项目名.模块名.…… | 公司项目，copyright由项目发起的公司所有 |
### 类命名
| 属性 | 约束 | 例 |
| :------------- | :---------------------------------------- | :----------------------------------------------------------: |
| 抽象类 | Abstract 或者 Base 开头 | BaseUserService |
| 枚举类 | Enum 作为后缀 | GenderEnum |
| 工具类 | Utils作为后缀 | StringUtils |
| 异常类 | Exception结尾 | RuntimeException |
| 接口实现类 | 接口名+ Impl | UserServiceImpl |
| 领域模型相关 | /DO/DTO/VO/DAO | 正例：UserDAO 反例： UserDo， UserDao |
| 设计模式相关类 | Builder，Factory等 | 当使用到设计模式时，需要使用对应的设计模式作为后缀，如ThreadFactory |
| 处理特定功能的 | Handler，Predicate, Validator | 表示处理器，校验器，断言，这些类工厂还有配套的方法名如handle，predicate，validate |
| 测试类 | Test结尾 | UserServiceTest， 表示用来测试UserService类的 |
| MVC分层 | Controller，Service，ServiceImpl，DAO后缀 | UserManageController，UserManageDAO |
### 方法
| 位置 | 单词 | 意义 | 例 |
| :----- | :----- | :----------------------------------------------------------- | :-----------: |
| Prefix | is | 对象是否符合期待的状态 | isValid |
| Prefix | can | 对象能否执行所期待的动作 | canRemove |
| Prefix | should | 调用方执行某个命令或方法是好还是不好,应不应该，或者说推荐还是不推荐 | shouldMigrate |
| Prefix | has | 对象是否持有所期待的数据和属性 | hasObservers |
| Prefix | needs | 调用方是否需要执行某个命令或方法 | needsMigrate |
### 变量&常量命名
变量使用驼峰命名法
常量名必须大写
### 通用命名规则
1. 尽量不要使用拼音；杜绝拼音和英文混用。对于一些通用的表示或者难以用英文描述的可以采用拼音，一旦采用拼音就坚决不能和英文混用。 正例： BeiJing， HangZhou 反例： validateCanShu
2. 命名过程中尽量不要出现特殊的字符，常量除外。
3. 尽量不要和jdk或者框架中已存在的类重名，也不能使用java中的关键字命名。
4. 妙用介词，如for(可以用同音的4代替), to(可用同音的2代替), from, with，of等。 如类名采用User4RedisDO，方法名getUserInfoFromRedis，convertJson2Map等。
## 继承结构及工程规范
| | | | |
| ---------------- | ------------------------------------------------------------ | ---------------------------------- | :----------------------------------------------------------: |
| 模块名称 | 模块说明xxxx
xxxx
xxxx
使用说明
xxxx
xxxx
xxxx | 示例 | 备注 |
| entity层 | 实体类命名与表名相同，首字母大写，如果表名存在_那么将_这去掉后首字母大写。 | 表名:like_log 实体名 LikeLog | **实体类属性必须与数据库字段名保持一致。** |
| mapper层 | 继承com.baomidou.mybatisplus.core.mapper.BaseMapper 要求实体泛型dao层下接口命名：实体名+Mapper 。 | LikeLogMapper | |
| service层 | 要求：接口继承com.baomidou.mybatisplus.extension.service.IService要求实体泛型 | | |
| service.impl层类 | 继承com.baomidou.mybatisplus.extension.service.impl.ServiceImpl，service层下接口命名：业务名称+Service 。service.impl层命名： 业务名称+ServiceImpl 。xxxx
xxxx
xxxx
使用说明
xxxx
xxxx
xxxx | LikeLogService；LikeLogServiceImpl | service层可以调用service层和dao层和其他项目。 service层下可再包一层bean层，用以存放数据结构的类，必须以Bean结尾。 平台service层内部调用的方法可以返回entity，但是被manage层调用的service方法只能返回dto或基本数据类型，不能返回entity到manage。 |
| manage层 | 调用其他服务的接口，通常使用Feign来实现 | ILikeLogMange | manage层下接口命名：I+业务名称+Manage。 |
| controller层 | 继承: org.jeecg.common.system.base.controller.JeecgControllercontroller层命名：以Controller结尾。 | LikeLogController | web/proxy/internal可用；**controller层不能出现dto** |
| form层 | web/proxy/internal可用；form下类命名：以Form结尾。 | LikeBaseInfoForm | form可以引用其他form form中不可以包含dto |
| vo层 | internal/platform 可用；vo层命名：以vo结尾，前缀不一定是entity。 | LikeLogDto | dto不能引用别人的dto |
| schedule类 | schedule层命名: 以业务名称开头，以Schedule结尾，前缀不一定是entity。 | SendEmailSchedule | |
| Idp类 | idp层命名：以IdpHandler结尾。 | ResumeIdpHandler | |
| util层 | util层命名：以Util或Utils结尾。 | MoneyUtil | |
| consts层 | 静态变量类consts层命名：以Const结尾。 | LikeLogConst | |
| helper层 | helper层命名：client名+Helper结尾。 | UserPlatformClientHelper | Helper层主要放置调用其它端client的工具类； Helper只可以出现调平台的代码和处理平台返回错误的代码； Helper不允许调其他helper； |
| filter | filter命名：以Filter结尾。 | AuthFilter | 只能出现在common包下面的filter包中 |
| resolver | 包名只能叫resolver且同一工程下只能有一个resolve包，只能出现在common包下的resolver包中，此包下只能有一个类文件且名称为：MvcExceptionResolver。 | | |
## Web URL标准
## Ajax返回数据规范
```java
// 正常返回
{
"flag": 1, // 数据状态标识
"data": { // 正常返回的相关数据，可以是 Object / Array
...
}
}
// 异常返回
{
"flag": 0, // 数据状态标识
"code": "***", // 异常标识code
"msg": "some error message." // 异常提示信息
}
```
## 数据库设计规范
## 数据库命令规范
1、所有数据库对象名称必须使用小写字母并用下划线分割
2、所有数据库对象名称禁止使用mysql保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来）
3、数据库对象的命名要能做到见名识意，并且最后不要超过32个字符
4、临时库表必须以tmp_为前缀并以日期为后缀，备份表必须以bak_为前缀并以日期(时间戳)为后缀
5、所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）
### 数据库命名规范
采用小写字母、数字（通常不需要）和下划线组成。禁止使用’-’，命名简洁、含义明确。
### 表命名
- 根据业务类型不同，采用不同的前缀，小写字母、下划线组成
- 长度控制在30个字符以内
推荐的命名规则
| 类型 | 前缀 | 说明 |
| -------------------- | ---------- | -------- |
| 业务表 | tb_ | |
| 关系表 | tr_ | |
| 历史表 | th_ | |
| 统计表 | ts_ | |
| 日志表 | tl_xx_log | |
| 系统表、字典表、码表 | sys_ | |
| 临时表 | tmp_ | 禁止使用 |
| 备份表 | bak_xx_ymd | |
| 视图 | view_ | 避免使用 |
## 数据库基本设计规范
### 所有表必须使用Innodb存储引擎
没有特殊要求（即Innodb无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用Innodb存储引擎（mysql5.5之前默认使用Myisam，5.6以后默认的为Innodb）Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。
### 数据库和表的字符集统一使用utf8mb4
兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效。
- 解读：在Mysql中的UTF-8并非“真正的UTF-8”，而utf8mb4”才是真正的“UTF-8”。
### 所有表和字段都需要添加注释
使用comment从句添加表和列的备注 从一开始就进行数据字典的维护
### 尽量控制单表数据量的大小，建议控制在500万以内
500万并不是MySQL数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题
可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小。
### 谨慎使用MySQL分区表
分区表在物理上表现为多个文件，在逻辑上表现为一个表 谨慎选择分区键，跨分区查询效率可能更低 建议采用物理分表的方式管理大数据
### 尽量做到冷热数据分离，减小表的宽度
MySQL限制每个表最多存储4096列，并且每一行数据的大小不能超过65535字节 减少磁盘IO,保证热数据的内存缓存命中率（表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO） 更有效的利用缓存，避免读入无用的冷数据 经常一起使用的列放到一个表中（避免更多的关联操作）
### 禁止在表中建立预留字段
预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型，所以无法选择合适的类型 对预留字段类型的修改，会对表进行锁定
### 禁止在数据库中存储图片，文件等大的二进制数据
通常文件很大，会短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机IO操作，文件很大时，IO操作很耗时 通常存储于文件服务器，数据库只存储文件地址信息
### 每张表必须设置一个主键ID，且这个主键ID使用自增主键（在满足需要的情况下尽量短），除非在分库分表环境下
- 解读：由于InnoDB组织数据的方式决定了需要有一个主键，而且若是这个主键ID是单调递增的可以有效提高插入的性能，避免过多的页分裂、减少表碎片提高空间的使用率。 而在分库分表环境下，则需要统一来分配各个表中的主键值，从而避免整个逻辑表中主键重复。
### 禁止使用外键，如果有外键完整性约束，需要应用程序控制
- 解读：外键会导致表与表之间耦合，UPDATE与DELETE操作都会涉及相关联的表，十分影响SQL的性能，甚至会造成死锁。
### 单表列数目必须小于30，若超过则应该考虑将表拆分
- 解读：单表列数太多使得Mysql服务器处理InnoDB返回数据之间的映射成本太高。
### 禁止在线上做数据库压力测试
### 禁止从开发环境，测试环境直接连接生成环境数据库
## 数据库字段设计规范
### 优先选择符合存储需要的最小的数据类型
原因
列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少也越少，在遍历时所需要的IO次数也就越多， 索引的性能也就越差
方法
1）将字符串转换成数字类型存储，如：将IP地址转换成整形数据。
mysql提供了两个方法来处理ip地址：
```sql
inet_aton 把ip转为无符号整型(4-8位)
inet_ntoa 把整型的ip转为地址
```
插入数据前，先用inet_aton把ip地址转为整型，可以节省空间。显示数据时，使用inet_ntoa把整型的ip地址转为地址显示即可。
2）对于非负型的数据（如自增ID、整型IP）来说，要优先使用无符号整型来存储
因为：无符号相对于有符号可以多出一倍的存储空间
```sql
SIGNED INT -2147483648~2147483647
UNSIGNED INT 0~4294967295
```
VARCHAR(N)中的N代表的是字符数，而不是字节数
使用UTF8存储255个汉字 Varchar(255)=765个字节。过大的长度会消耗更多的内存
### 避免使用TEXT、BLOB数据类型，最常见的TEXT类型可以存储64k的数据
建议把BLOB或是TEXT列分离到单独的扩展表中
Mysql内存临时表不支持TEXT、BLOB这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。
而且对于这种数据，Mysql还是要进行二次查询，会使sql性能变得很差，但是不是说一定不能使用这样的数据类型。
如果一定要使用，建议把BLOB或是TEXT列分离到单独的扩展表中，查询时一定不要使用select * 而只需要取出必要的列，不需要TEXT列的数据时不要对该列进行查询。
TEXT或BLOB类型只能使用前缀索引
因为MySQL对索引字段长度是有限制的，所以TEXT类型只能使用前缀索引，并且TEXT列上是不能有默认值的。
### 避免使用ENUM类型
1、修改ENUM值需要使用ALTER语句
2、ENUM类型的ORDER BY操作效率低，需要额外操作
3、禁止使用数值作为ENUM的枚举值
### 必须把字段定义为NOT NULL并且提供默认值
原因：
1、索引NULL列需要额外的空间来保存，所以要占用更多的空间；
2、进行比较和计算时要对NULL值做特别的处理
- 解读：
- NULL的列使索引/索引统计/值比较都更加复杂，对MySQL来说更难优化；
- NULL这种类型Msql内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多；
- NULL值需要更多的存储空，无论是表还是索引中每行中的NULL的列都需要额外的空间来标识。
### 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间
TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。
TIMESTAMP 占用4字节和INT相同，但比INT可读性高
超出TIMESTAMP取值范围的使用DATETIME类型存储。
经常会有人用字符串存储日期型的数据（不正确的做法）：
缺点1：无法用日期函数进行计算和比较
缺点2：用字符串存储日期要占用更多的空间
### 同财务相关的金额类数据必须使用decimal类型
1、非精准浮点：float,double
2、精准浮点：decimal
Decimal类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每4个字节可以存储9位数字，并且小数点要占用一个字节。可用于存储比bigint更大的整型数据。
### 如果存储的字符串长度几乎相等，使用CHAR定长字符串类型。
- 解读：能够减少空间碎片，节省存储空间。
### 禁用保留字，如DESC、RANGE、MARCH等，请参考Mysql官方保留字
## 索引设计规范
### 4.4.1 限制每张表上的索引数量，建议单张表索引不超过5个
索引并不是越多越好！索引可以提高效率同样可以降低效率。
索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。
因为mysql优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加mysql优化器生成执行计划的时间，同样会降低查询性能。
### 4.4.2 禁止给表中的每一列都建立单独的索引
5.6版本之前，一个sql只能使用到一个表中的一个索引，5.6以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好
### 4.4.3 每个Innodb表必须有个主键
Innodb是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。
每个表都可以有多个索引，但是表的存储顺序只能有一种 Innodb是按照主键索引的顺序来组织表的。
不要使用更新频繁的列作为主键，不适用多列主键（相当于联合索引） 不要使用UUID、MD5、HASH、字符串列作为主键（无法保证数据的顺序增长）。
主键建议使用自增ID值。
### 4.4.4 索引规约
【建议】（1）避免在更新比较频繁、区分度不高的列上单独建立索引
- 解读：区分度不高的列单独创建索引的优化效果很小，但是较为频繁的更新则会让索引的维护成本更高。
【强制】（2） JOIN的表不允许超过五个。需要JOIN的字段，数据类型必须绝对一致; 多表关联查询时，保证被关联的字段需要有索引
- 解读：太多表的JOIN会让Mysql的优化器更难权衡出一个“最佳”的执行计划（可能性为表数量的阶乘），同时要注意关联字段的类型、长度、字符编码等等是否一致。
【强制】（3）在一个联合索引中，若第一列索引区分度等于1，那么则不需要建立联合索引
- 解读：索引通过第一列就能够完全定位的数据，所以联合索引的后边部分是不需要的。
【强制】（4）建立联合索引时，必须将区分度更高的字段放在左
- 解读：区分度更高的列放在左边，能够在一开始就有效的过滤掉无用数据。提高索引的效率，相应我们在Mapper中编写SQL的WHERE条件中有多个条件时，需要先看看当前表是否有现成的联合索引直接使用，注意各个条件的顺序尽量和索引的顺序一致。
【建议】（5）利用覆盖索引来进行查询操作，避免回表
- 解读：覆盖查询即是查询只需要通过索引即可拿到所需DATA，而不再需要再次回表查询，所以效率相对很高。我们在使用EXPLAIN的结果，extra列会出现："using index"。这里也要强调一下不要使用“SELECT * ”，否则几乎不可能使用到覆盖索引。
【建议】（6）在较长VARCHAR字段,例如VARCHAR(100)上建立索引时，应指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可
- 解读：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，若长度为20的索引，区分度会高达90%以上，则可以考虑创建长度例为20的索引，而非全字段索引。例如可以使用SELECT COUNT(DISTINCT LEFT(lesson_code, 20)) / COUNT(*) FROM lesson;来确定lesson_code字段字符长度为20时文本区分度。
【建议】（7）如果有ORDER BY的场景，请注意利用索引的有序性。ORDER BY最后的字段是联合索引的一部分，并且放在索引组合顺序的最后，避免出现file_sort的情况，影响查询性能。
- 解读：
- 假设有查询条件为WHERE a=? and b=? ORDER BY c；存在索引：a_b_c，则此时可以利用索引排序；
- 反例：在查询条件中包含了范围查询，那么索引有序性无法利用，如:WHERE a>10 ORDER BY b; 索引a_b无法排序。
【建议】（8）在where中索引的列不能某个表达式的一部分，也不能是函数的参数
- 解读：即是某列上已经添加了索引，但是若此列成为表达式的一部分、或者是函数的参数，Mysql无法将此列单独解析出来，索引也不会生效。
【建议】 （9）我们在where条件中使用范围查询时，索引最多用于一个范围条件，超过一个则后边的不走索引
- 解读：Mysql能够使用多个范围条件里边的最左边的第一个范围查询，但是后边的范围查询则无法使用。
【建议】 （10）在多个表进行外连接时，表之间的关联字段类型必须完全一致
- 解读：当两个表进行Join时，字段类型若没有完全一致，则加索引也不会生效，这里的完全一致包括但不限于字段类型、字段长度、字符集、collection等等。
## 常见索引列建议
1、出现在SELECT、UPDATE、DELETE语句的WHERE从句中的列
2、包含在ORDER BY、GROUP BY、DISTINCT中的字段
并不要将符合1和2中的字段的列都建立一个索引，通常将1、2中的字段建立联合索引效果更好
3、多表join的关联列
## 如何选择索引列的顺序
建立索引的目的是：希望通过索引进行数据查找，减少随机IO，增加查询性能 ，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。
1、区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）；
2、尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO性能也就越好）；
3、使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）。
## 避免建立冗余索引和重复索引
因为这样会增加查询优化器生成执行计划的时间。
**重复索引示例：**primary key(id)、index(id)、unique index(id)
**冗余索引示例：**index(a,b,c)、index(a,b)、index(a)
## 优先考虑覆盖索引
对于频繁的查询优先考虑使用覆盖索引。
覆盖索引：就是包含了所有查询字段(where,select,ordery by,group by包含的字段)的索引
覆盖索引的好处：
- 避免Innodb表进行索引的二次查询
- Innodb是以聚集索引的顺序来存储的，对于Innodb来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询 ，减少了IO操作，提升了查询效率。
- 可以把随机IO变成顺序IO加快查询效率
由于覆盖索引是按键值的顺序存储的，对于IO密集型的范围查找来说，对比随机从磁盘读取每一行的数据IO要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的IO转变成索引查找的顺序IO。
## 索引SET规范
**尽量避免使用外键约束**
1、不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引；
2、外键可用于保证数据的参照完整性，但建议在业务端实现；
3、外键会影响父表和子表的写操作从而降低性能。
## 数据库SQL开发规范
### 建议使用预编译语句进行数据库操作
预编译语句可以重复使用这些计划，减少SQL编译所需要的时间，还可以解决动态SQL所带来的SQL注入的问题 只传参数，比传递SQL语句更高效 相同语句可以一次解析，多次使用，提高处理效率。
### 不允许使用属性隐式转换
隐式转换会导致索引失效。如：select name,phone from customer where id = '111';
解读：假设我们在手机号列上添加了索引，然后执行下面的SQL会发生什么？explain SELECT user_name FROM parent WHERE phone=13812345678; 很明显就是索引不生效，会全表扫描。
### 充分利用表上已经存在的索引
避免使用双%号的查询条件。
如a like '%123%'，（如果无前置%,只有后置%，是可以用到列上的索引的）
解读：根据索引的最左前缀原理，%开头的模糊查询无法使用索引，可以使用ES来做检索。
一个SQL只能利用到复合索引中的一列进行范围查询
如：有 a,b,c列的联合索引，在查询条件中有a列的范围查询，则在b,c列上的索引将不会被用到，在定义联合索引时，如果a列要用到范围查找的话，就要把a列放到联合索引的右侧。
使用left join或 not exists来优化not in操作
因为not in 也通常会使用索引失效。
### 数据库设计时，应该要对以后扩展进行考虑
### 程序连接不同的数据库使用不同的账号，禁止跨库查询
1、为数据库迁移和分库分表留出余地
2、降低业务耦合度
3、避免权限过大而产生的安全风险
### 禁止使用SELECT * 必须使用SELECT <字段列表> 查询
原因：
1. 消耗更多的CPU和IO以网络带宽资源
2. 无法使用覆盖索引
3. 可减少表结构变更带来的影响
4. 读取不需要的列会增加CPU、IO、NET消耗；
### 禁止使用不含字段列表的INSERT语句
如：insert into values ('a','b','c');
应使用insert into t(c1,c2,c3) values ('a','b','c');
### 避免使用子查询，可以把子查询优化为join操作
通常子查询在in子句中，且子查询中为简单SQL(不包含union、group by、order by、limit从句)时，才可以把子查询转化为关联查询进行优化。
子查询性能差的原因：
1、子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响；
3、特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大；
3、由于子查询会产生大量的临时表也没有索引，所以会消耗过多的CPU和IO资源，产生大量的慢查询。
### 避免使用JOIN关联太多的表
对于Mysql来说，是存在关联缓存的，缓存的大小可以由join_buffer_size参数进行设置。
在Mysql中，对于同一个SQL多关联（join）一个表，就会多分配一个关联缓存，如果在一个SQL中关联的表越多，所占用的内存也就越大。
如果程序中大量的使用了多表关联的操作，同时join_buffer_size设置的也不合理的情况下，就容易造成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性。
同时对于关联操作来说，会产生临时表操作，影响查询效率Mysql最多允许关联61个表，建议不超过5个。
### 减少同数据库的交互次数
数据库更适合处理批量操作 合并多个相同的操作到一起，可以提高处理效率
### 对应同一列进行or判断时，使用in代替or
应尽量避免在WHERE子句中使用or作为连接条件
in的值不要超过500个in操作可以更有效的利用索引，or大多数情况下很少能利用到索引。
解读：根据情况可以选择使用UNION ALL来代替OR。
### 禁止使用order by rand() 进行随机排序
会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的值进行排序，并且可能会对每一行都生成一个随机值，如果满足条件的数据集非常大，就会消耗大量的CPU和IO及内存资源。
推荐在程序中获取一个随机值，然后从数据库中获取数据的方式
### WHERE从句中禁止对列进行函数转换和计算
对列进行函数转换或计算时会导致无法使用索引。
不推荐：
```sql
where date(create_time)='20190101'
```
推荐：
```sql
where create_time >= '20190101' and create_time < '20190102'
```
### 在明显不会有重复值时使用UNION ALL而不是UNION
1、UNION会把两个结果集的所有数据放到临时表中后再进行去重操作
2、UNION ALL不会再对结果集进行去重操作
### 拆分复杂的大SQL为多个4.11.1小SQL
1、大SQL：逻辑上比较复杂，需要占用大量CPU进行计算的SQL
2、MySQL：一个SQL只能使用一个CPU进行计算
3、SQL拆分后可以通过并行执行来提高处理效率
### 禁止使用外键与级联，一切外键概念必须在应用层解决
- 解读：外键与级联更新适用于单机低并发，不适合分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。
## 数据库操作行为规范
### 超100万行的批量写（UPDATE、DELETE、INSERT）操作，要分批多次进行操作
大批量操作可能会造成严重的主从延迟
主从环境中，大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间，而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况
binlog日志为row格式时会产生大量的日志
大批量写操作会产生大量日志，特别是对于row格式二进制数据而言，由于在row格式中会记录每一行数据的修改，我们一次修改的数据越多，产生的日志量也就会越多，日志的传输和恢复所需要的时间也就越长，这也是造成主从延迟的一个原因。
避免产生大事务操作
大批量修改数据，一定是在一个事务中进行的，这就会造成表中大批量数据进行锁定，从而导致大量的阻塞，阻塞会对MySQL的性能产生非常大的影响。
特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库，因此一定要注意大批量写操作要进行分批。
### 4.11.2 对于大表使用pt-online-schema-change修改表结构
1、避免大表修改产生的主从延迟
2、避免在对表字段进行修改时进行锁表
对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是生产环境，是不能容忍的。
pt-online-schema-change它会首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。
把原表中新增的数据也复制到新表中，在行所有数据复制完成之后，把新表命名成原表，并把原来的表删除掉。
把原来一个DDL操作，分解成多个小的批次进行。
### 4.11.3 禁止为程序使用的账号赋予super权限
当达到最大连接数限制时，还运行1个有super权限的用户连接super权限只能留给DBA处理问题的账号使用。
### 4.11.4 对于程序连接数据库账号，遵循权限最小原则
程序使用数据库账号只能在一个DB下使用，不准跨库 程序使用的账号原则上不准有drop权限。
## 接口设计规范
## 基本规范
### 公共参数
公共参数是每个接口都要携带的参数，描述每个接口的基本信息，用于统计或其他用途，放在header或url参数中。例如：
| 字段名称 | 说明 |
| -------- | ------------------------ |
| version | 客户端版本。1.0.0 |
| token | 登录令牌 |
| os | 手机系统版本。12 |
| from | 请求来源。android/ios/h5 |
| screen | 手机尺寸。1080*1920 |
| model | 机型。IPhone7 |
| net | 网络状态。wifi |
### 响应数据
为了方便给客户端响应，响应数据会包含三个属性，状态码（code）,信息描述（message）,响应数据（data）。客户端根据状态码及信息描述可快速知道接口，如果状态码返回成功，再开始处理数据。
array类型数据。通过list字段，保证data的Object结构。
分页类型数据。返回总条数，用于判断是否可以加载更多。
```json
// object类型数据
{
"code":1,
"msg":"成功",
"data":{}
}
// array类型数据。
{
"code":1,
"msg":"成功",
"data":{
"list":[]
}
}
// 分页类型数据。
{
"code":1,
"msg":"成功",
"data":{
"list":[]
"total":"10"
}
}
```
列表类数据接口，无论是否要求分页，最好支持分页，pageSize=Integer.Max即可。
响应结果定义及常用方法：
```java
public class R implements Serializable {
private static final long serialVersionUID = 793034041048451317L;
private int code;
private String message;
private Object data = null;
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
public Object getData() {
return data;
}
/**
* 放入响应枚举
*/
public R fillCode(CodeEnum codeEnum){
this.setCode(codeEnum.getCode());
this.setMessage(codeEnum.getMessage());
return this;
}
/**
* 放入响应码及信息
*/
public R fillCode(int code, String message){
this.setCode(code);
this.setMessage(message);
return this;
}
/**
* 处理成功，放入自定义业务数据集合
*/
public R fillData(Object data) {
this.setCode(CodeEnum.SUCCESS.getCode());
this.setMessage(CodeEnum.SUCCESS.getMessage());
this.data = data;
return this;
}
}
```
### 字段类型规范
统一使用String类型。某些情况，统一使用String可以防止解析失败，减少类型转化操作。
Boolean类型，1是0否。客户端处理时，非1都是false。
```java
if("1".equals(isVip)){
}else{
}
```
status类型字段，从1+开始，区别Boolean的0和1。“0”有两种含义，（1）Boolean类型的false，（2）默认的status
### 上传/下载
上传/下载，参数增加文件md5，用于完整性校验（传输过程可能丢失数据）。
### 避免精度丢失
缩小单位保存数据，如：钱以分为单位、距离以米为单位。
## 调用接口的先决条件-token
获取token一般会涉及到几个参数`appid`，`appkey`，`timestamp`，`nonce`，`sign`。我们通过以上几个参数来获取调用系统的凭证。
`appid`和`appkey`可以直接通过平台线上申请，也可以线下直接颁发。`appid`是全局唯一的，每个`appid`将对应一个客户，`appkey`需要高度保密。
`timestamp`是时间戳，使用系统当前的unix时间戳。时间戳的目的就是为了减轻DOS攻击。防止请求被拦截后一直尝试请求接口。服务器端设置时间戳阀值，如果请求时间戳和服务器时间超过阀值，则响应失败。
`nonce`是随机值。随机值主要是为了增加`sign`的多变性，也可以保护接口的幂等性，相邻的两次请求`nonce`不允许重复，如果重复则认为是重复提交，响应失败。
`sign`是参数签名，将`appkey`，`timestamp`，`nonce`拼接起来进行md5加密（当然使用其他方式进行不可逆加密也没问题）。
`token`，使用参数`appid`，`timestamp`，`nonce`，`sign`来获取token，作为系统调用的唯一凭证。`token`可以设置一次有效（这样安全性更高），也可以设置时效性，这里推荐设置时效性。如果一次有效的话这个接口的请求频率可能会很高。`token`推荐加到请求头上，这样可以跟业务参数完全区分开来。
## 使用POST作为接口请求方式
一般调用接口最常用的两种方式就是GET和POST。两者的区别也很明显，GET请求会将参数暴露在浏览器URL中，而且对长度也有限制。为了更高的安全性，所有接口都采用POST方式请求。
### GET、POST、PUT、DELETE对比
#### 1. GET
- 安全且幂等
- 获取表示
- 变更时获取表示（缓存）
适合查询类的接口使用
#### 2. POST
- 不安全且不幂等
- 使用服务端管理的（自动产生）的实例号创建资源
- 创建子资源
- 部分更新资源
- 如果没有被修改，则不过更新资源（乐观锁）
适合数据提交类的接口使用
#### 3. PUT
- 不安全但幂等
- 用客户端管理的实例号创建一个资源
- 通过替换的方式更新资源
- 如果未被修改，则更新资源（乐观锁）
适合更新数据的接口使用
#### 4. DELETE
- 不安全但幂等
- 删除资源
适合删除数据的接口使用
列表界面
```json
// 静态列表
{
"name": "张三",
"sex": "男",
"age": "20岁",
"nickName": "小张"
}
// 动态列表
{
"userInfos":[
{
"key":"姓名",
"value":"张三"
},{
"key":"性别",
"value":"男"
},{
"key":"年龄",
"value":"20岁"
},{
"key":"昵称",
"value":"小张"
}]
}
```
多个boolean可以flag替换
```json
{
"flag":"7" // 二进制：111，三位分别表示三个boolean字段
}
long flag = 7;
System.out.println("bit="+Long.toBinaryString(flag));
System.out.println("第一位="+((flag&1)==1));
System.out.println("第二位="+((flag&2)==1));
System.out.println("第三位="+((flag&4)==1));
```
## 响应状态码
采用http的状态码进行数据封装，例如200表示请求成功，4xx表示客户端错误，5xx表示服务器内部发生错误。状态码设计参考如下：
| 分类 | 描述 |
| ---- | -------------------------------------------- |
| 1xx | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2xx | 成功 |
| 3xx | 重定向，需要进一步的操作以完成请求 |
| 4xx | 客户端错误，请求包含语法错误或无法完成请求 |
| 5xx | 服务端错误 |
状态码枚举类：
```java
public enum CodeEnum {
// 根据业务需求进行添加
SUCCESS(200,"处理成功"),
ERROR_PATH(404,"请求地址错误"),
ERROR_SERVER(505,"服务器内部发生错误");
private int code;
private String message;
CodeEnum(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
```
### 正常响应
响应状态码2xx
- 200：常规请求
- 201：创建成功
### 重定向响应
响应状态码3xx
- 301：永久重定向
- 302：暂时重定向
### 客户端异常
响应状态码4xx
- 403：请求无权限
- 404：请求路径不存在
- 405：请求方法不存在
### 服务器异常
响应状态码5xx
- 500：服务器异常