常见SQL、API接口等常见约定

Mysql 常见约定

    一、基础规范
    
    	1、表存储引擎必须使用InnoDB。
    	2、表字符集使用utf8mb4。
   		3、禁止使用存储过程、视图、触发器、Event。它们对数据库性能影响较大，调试、排错、迁移都比较困难，扩展性较差。
		4、禁止在数据库中存储大文件，例如照片，可以将大文件存储在对象存储系统，数据库中存储路径。
		5、测试、开发、线上数据库环境必须隔离。

	
	二、命名规范
	
    	1、库名、表名、字段名必须使用小写字母或数字，采用下划线分隔，长度不要超过32字符，禁止出现数字开头，禁止两个下划线中间只出现数字。
    	2、表名不使用复数名词、mysql保留字。
    	3、数据库名与应用名称尽量一致，比如mimo。
    	4、表的命名最好是遵循“业务名称_表的作用”,例如商品服务下的表product_attr。
    	5、表达是与否概念的字段，必须使用is_xxx的方式命名，数据类型是bit（1表示是，0表示否），注意：POJO类中的任何布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。
    	6、逻辑外键按照“外键所属表名称_id”命名，例如同一模块，外键所属表product_spu则外键名称是 spu_id\product_spu_id。
	
	
	三、表设计规范
	
    	1、表设计基本符合数据库三范式。
    	2、表必须有主键，推荐使用UNSIGNED整数为主键。
    	3、禁止使用物理外键，如果要保证完整性，应由应用程序实现。外键使得表之间相互耦合，影响update/delete等SQL性能，有可能造成死锁，高并发情况下容易成为数据库瓶颈。
    	4、小数类型为decimal，禁止使用float和double。在存储的时候，float 和 double 都存在精度损失的问题，很可能在比较值的时候，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数并分开存储。如果金额之类尽量统一单位用整型存储。
		5、如果存储的字符串长度几乎相等，使用CHAR定长字符串类型，能够减少碎片，查询性能高。
		7、varchar是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
		8、表必备字段： id、create_time、create_by，非必须字段：update_time、update_by、deleted。其中id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。 create_time, update_time的类型均为 datetime 类型。
		9、表和字段都要有中文含义注释，如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。
		10、字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：1） 不是频繁修改的字段。2） 不是唯一索引的字段。3） 不是 varchar 超长字段，更不能是 text 字段。
		11、字段要根据实际业务设计合适的存储长度，这样不但节约数据库表空间、节约索引存储，更重要的是提升检索速度,比如字典值字段类型尽量用tinyint，如不满足需求可以换成smallint、int。
		12、必须把字段定义为NOT NULL并设默认值。1）NULL的列使用索引，索引统计，值都更加复杂，MySQL更难优化；2）NULL需要更多的存储空间；3）NULL只能采用IS NULL或者IS NOT NULL，而在=/!=/in/not in时有大坑。
		13、使用TINYINT来代替ENUM，ENUM增加新值要进行DDL操作。
		
		
	四、索引规范
	
		1、主键索引名为 pk_字段名；唯一索引名为 uk_字段名； 普通索引名则为 idx_字段名。
		2、业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。
		3、超过三个表禁止 join，需要 join 的字段，数据类型保持绝对一致； 多表关联查询时，保证被关联的字段需要有索引。
		4、在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。区分度公式count(distinct left(列名, 索引长度))/count(*)。
		5、页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
		6、如果有 order by 的场景，请注意利用索引的有序性。 order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。例如：where a=? and b=? order by c; 索引： a_b_c。
		7、建组合索引的时候，区分度最高的在最左边。存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如： where c>? and d=?那么即使 c 的区分度更高，也必须把 d 放在索引的最前列， 即建立组合索引 idx_d_c。
		8、防止因字段类型不同造成的隐式转换，导致索引失效。
		9、单张表索引数量建议控制在5个以内，太多索引会影响写性能。
		10、组合索引字段数不建议超过5个，如果5个字段还不能极大缩小row范围，八成是设计有问题。
		11、不建议在频繁更新的字段上建立索引。
		12、理解组合索引最左前缀原则，避免重复建设索引，如果建立了(a,b,c)，相当于建立了(a), (a,b), (a,b,c)。
		
		
	五、SQL使用注意事项
	
		1、禁止使用select *，显式指定必要字段。
		2、insert必须指定字段，禁止使用insert into T values()，指定字段插入，在表结构变更时，能减少对应用程序的影响。
		3、禁止在where条件列使用函数或者表达式，导致不能命中索引，全表扫描。
		4、对于数据库中表记录的查询，只要涉及多个表，都需要在列名前加表的别名（或表名）进行限定。
		5、in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在 1000 个之内。

API 接口约定

	一、API 接口定义规范

		1.服务接口尽可能大粒度，每个服务方法都应该代表一个功能，而不只是一个步骤
		2.不可使用过于抽象的通用接口，如：Map query(Map)
		3.服务接口增加方法，或服务模型增加字段，可向后兼容；删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容(枚举类型只允许入参)，需通过变更版rpc本号升级
		4.过期接口与参数必须使用@Deprecated 注解,相隔一到两个版本再做删除
		5.跨应用间 RPC 调用优先考虑使用 Result 方式，调用方用isSuccess()判断调用是否成功
		6.使用单参DTO方式传参
	

	二、API 接口命名规范--前缀

		动词加名词组成。举例：
			1.新增 insert\create
			2.删除 delete\remove
			3.修改 update\modify
			4.查询 find\query 
			5.批量 batch
			6.设置 set

阿里云MQ 命名约定

	1、TOPIC命名:   项目名_*_MASTER/DEV/PRE
	
		例如: 
			MIMO_EVENTBUS_MASTER *可以没有,也可以是任意大写字符串 比如 	MIMO_EVENTBUS_DELIVER_MASTER表明是事件总线的延迟队列
	
	2、GROUPID命名：  GID_项目名_P/C_模块名_MASTER/DEV/PRE
	
		例如:
			GID_MIMO_ORDER_P_MASTER P代表producer,C代表consumer P/C 可以忽略