mysql .pdf建表的一些规则 和注意事项

2.1命名规则 【推荐】库名与应用名称尽量一致。 【强制】表名 不使用复数名词 【强制】字段名 必须使用小写字母，禁止出现数字开头禁止两个下划线中间只出现数字。 【强制】禁用保留字，如 desc、range、match、delayed 等 参考 MySQL 官方保留字。 1 【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。 说明：pk_即 primary key；uk_即 unique key；idx_即 index 的简称。 1 【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是，0 表示否）。 注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在<resultMap>设置从 is_xxx 到 Xxx 的映射关 系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。 说明：任何字段如果为非负数，必须是 unsigned。 正例：表达逻辑删除的字段名 is_delet ### MySQL建表规则与注意事项详解 #### 一、命名规则 **1.1 库名与应用名称一致性** - **推荐做法**：建议数据库的名字与应用程序的名称保持一致，这样可以便于开发人员理解和记忆，同时也方便后期维护。 **1.2 表名使用单数名词** - **强制规定**：在定义表名时，应使用单数名词而不是复数形式，以避免混淆和减少错误的发生概率。 **1.3 字段名规范** - **强制规定**：所有字段名必须使用小写字母，禁止数字开头，并且不允许在两个下划线之间只包含数字。这些规定有助于确保字段名的一致性和可读性，降低出错几率。 **1.4 避免使用保留字** - **强制规定**：禁止使用MySQL保留关键字作为字段名，如`desc`、`range`、`match`、`delayed`等。参考MySQL官方文档获取完整的保留字列表，确保所使用的字段名不会与保留字冲突。 **1.5 索引命名规范** - **强制规定**：主键索引名为`pk_字段名`；唯一索引名为`uk_字段名`；普通索引名为`idx_字段名`。这种命名方式有助于快速识别不同类型的索引，提高代码可读性和维护性。 **1.6 是/否概念字段命名** - **强制规定**：对于表示是否概念的字段，必须采用`is_xxx`的方式进行命名，数据类型统一使用`unsigned tinyint`（1表示是，0表示否）。此外，在POJO类中的布尔类型变量不应带有`is_`前缀，并在`<resultMap>`中建立相应的映射关系。这种做法有利于明确字段的取值含义和范围，减少误解。 **1.7 数据类型非负数使用unsigned** - **说明**：对于所有非负数字段，建议使用`unsigned`属性，这不仅可以节约存储空间，还能提高查询效率。 **1.8 表命名推荐** - **推荐做法**：表名建议遵循“业务名称_表的作用”的原则，这样可以更直观地反映出表的功能和用途。 #### 二、数据类型与存储 **2.1 小数类型使用decimal** - **强制规定**：所有涉及小数运算的字段都应使用`decimal`类型，而避免使用`float`和`double`。这是因为`decimal`类型提供了更高的精度，更适合金融计算等场景。 **2.2 定长字符串类型char** - **强制规定**：如果存储的字符串长度几乎相同，则应使用`char`类型，以节省存储空间并提高查询效率。 **2.3 可变长字符串类型varchar** - **强制规定**：对于长度变化较大的字符串字段，应使用`varchar`类型。为了提高性能，建议长度不要超过5000个字符。 **2.4 必备字段** - **强制规定**：每个表都应该包含以下三个字段：`id`（主键）、`create_time`（创建时间）、`update_time`（更新时间）。这些字段有助于记录数据的生命周期信息，方便后续的数据管理和分析。 **2.5 逻辑删除** - **强制规定**：在数据库中应使用逻辑删除而非物理删除。通常会增加一个`is_delete`字段来标记数据是否被删除。 **2.6 字段注释更新** - **推荐做法**：当字段含义发生变更或新增状态时，应及时更新字段注释，保持文档与实际内容的一致性。 **2.7 字段冗余** - **推荐做法**：适当增加冗余字段可以提高查询性能，但必须确保数据的一致性。例如，可以通过触发器等机制来同步更新冗余字段。 **2.8 图片文件存储** - **强制规定**：禁止将图片、文件等二进制大数据直接存储在数据库中。这类数据应存放在专门的文件系统或对象存储服务中，以减轻数据库压力。 **2.9 数据类型优化** - **强制规定**：尽可能使用更小的数据类型，如能使用`tinyint`就不要使用`smallint`或`int`类型，以减少存储空间消耗。 **2.10 默认值** - **推荐做法**：尽可能为字段设置默认值，避免出现`NULL`值，有助于简化查询和减少数据处理的复杂度。 **2.11 外键约束** - **强制规定**：在实际开发过程中，不建议使用外键约束。虽然外键可以确保数据一致性，但在高并发场景下可能会降低性能。 **2.12 冗余字段一致性** - **强制规定**：对于冗余字段，必须保证类型的一致性，以避免在执行联表查询时出现类型转换导致的速度下降问题。 **2.13 字符集选择** - **推荐做法**：新建数据库时，建议选择`utf-8`字符集，排序规则采用`utf8_general_ci`，以确保兼容性和国际化需求。 #### 三、业务角度下的建表规范 **3.1 字段垂直分表** - **推荐做法**：根据字段的热度、冷度、静态性、大小等因素进行垂直分表，将热点数据和冷数据分开存储，以优化查询性能。 **3.2 水平分表** - **推荐做法**：当单表数据量过大时，可以采用水平分表策略，通过哈希等方式将数据分散到多个表中，以提高查询效率。 #### 四、索引使用规范 **4.1 需要建索引** - **说明**：对于经常用于查询条件、排序、分组的字段，应该建立索引以提高查询效率。但是，需要注意索引的合理数量，过多的索引会导致写入性能下降。 **4.2 不建索引的情况** - **说明**：对于不常用的查询条件，或者字段数据分布过于均匀的情况，可以考虑不建立索引。 **4.3 容易犯的索引错误** - **常见问题**：常见的索引错误包括未使用最左前缀原则、未覆盖完整查询条件等。在设计索引时应充分考虑查询的实际需求，避免不必要的索引。 以上规则和注意事项不仅适用于特定的电商平台场景，也适用于其他业务场景，旨在提高数据库的设计质量、运行效率以及维护的便捷性。