这里说明在创建 TDSQL-C MySQL 集群后的相关使用规范建议。
一、数据库权限规范
·所有 DDL（例如：创建表，更改表结构等）只有通过评审后，由 DBA 通过数据库管理工具（DMC）执行，在业务低峰期操作上线。
·权限需要进行细粒度控制，读写权限分开，运维和开发权限要分开。
·DDL 操作保留操作日志。
二、库表规范
·InnoDB 是 MySQL 中支持事务的一种引擎，如果要在 MySQL 数据库中创建表，并且需要使用事务功能，那么必须使用 InnoDB 引擎来创建表，适配 MySQL 的其它引擎不支持事务。
·小数类型需使用 decimal 类型来定义，禁止使用 float 和 double。
注意：说明：
注意：float 和 double 在存储的时候，存在精度损失的问题，很可能在值比较的时候得到的结果有误。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。
·禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 保留字。
·数据表必须有主键，可以使用业务相关，有序且具有唯一性的字段作为主键，也可以使用业务无关的自增长字段作为主键。
注意：说明：
注意：无主键容易导致主库执行速度慢和复制延迟问题。
·创建表时需为表中的字段设置默认值，并且将字段设置为 NOT NULL，以避免在插入数据时出现空值或缺失值的情况，数字类型默认值推荐给0，varchar 等字符类型的默认值推荐空字符串，如''。
·建议表包含两个字段：create_time，update_time，且均为 datetime 类型。
注意：说明：
注意：数据仓库拖取数据时可以利用这两个统一字段无需询问业务。
在数据库出现意外时可以判断数据进入数据库和修改的时间，在极端情况可以帮助数据恢复的判断。
·控制单表字段数量，字段上限50个。
·如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
·字段允许适当跨表冗余，以避免关联查询，提高查询性能，但必须考虑数据一致。
注意：说明：
注意：冗余字段应遵循：
·合适的存储长度（不建议使用 LONG TEXT，BLOB 等长类型字段），不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。
三、索引规范
·避免因为字段类型不同造成的隐式转换，导致索引失效。
·业务上具有唯一特性的字段，即使是多个字段的组合，建议在所有具有唯一特性字段的最小集合上建立唯一索引。
例如：一个表含有 a，b，c，d，e，f 字段，在业务上 ab 和 ef 分别是具有唯一特性的字段集合，那么最好在最小集合 ab 和 ef 上分别建立唯一索引。
注意：说明：
·尽量在定长的字段（如：INT）上建立索引；在 varchar 字段上建立索引时，必须指定索引长度，无需对全字段建立索引，根据实际文本区分度决定索引长度即可。
注意：说明：
注意：索引长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引区分度会高达90%以上，可以使用 count(distinct left(列名，索引长度))/count(*) 的区分度来确定（有区分度的放前面，没有区分度的放后面）。
·页面搜索避免使用左模糊（如：SELECT * FROM users WHERE u_name LIKE ‘%hk’）或者全模糊，避免从索引扫描退化为全表扫描，如果需要请在应用层解决。
注意：说明：
注意：索引文件具有 B-tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
·利用覆盖索引来进行查询操作，避免回表，但是覆盖索引加的字段不能太多，要兼顾写性能。
注意：说明：
注意：能够建立索引的种类：主键索引、唯一索引、普通索引，而覆盖索引是一种查询的效果，利用 explain 的结果，extra 列会出现：using index。
·SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好。
·创建组合索引的时候，区分度最高的在左边。
·单张表的索引数量控制在5个以内，或不超过表字段个数的20%。
·创建索引避免有如下误解：
·误认为一个查询就需要建一个索引。
·误认为索引会消耗空间、严重拖慢更新和新增速度。
·误认为业务的唯一性一律需要在应用层通过“先查后插”方式能解决。