MySQL 数据库铁律(小结)
更新时间：2019年09月09日 09:38:51 作者：郭朝
这篇文章主要介绍了MySQL 数据库铁律，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
好的数据库规范有助于减少软件实现的复杂度，降低沟通成本，本铁律主要涵盖了建库建表、建索引、写 SQL、ORM 映射等方面的处理约定。
1.建库铁律
| - | 铁律 | Level | 备注 |
|---|---|---|---|
| 字符集 | 使用 utf-8。如果存储的是表情则选用 utf8mb4 进行存储。 | 强制 | |
| 排序规则 | 使用 utf8_general_ci | 强制 |
2.建表铁律
| - | 铁律 | Level | 备注 |
|---|---|---|---|
| 注释 | 一定要有字段注释。 | 强制 | |
| 编码 | 使用 utf-8。如果存储的是表情则选用 utf8mb4 进行存储。 | 强制 | |
| 是否概念的字段 | 必须用 is_xx 命名，数据类型是 unsigned tinyint（1是0否）例如 is_deleted（1删除0未删除）。 | 强制 | 任何字段如果非负数必须unsigned |
| 表名、字段名 | 只能使用小写字母、下划线或者数字；禁止以下划线或者数字开头；禁止两个下划线之间只出现数字；禁用保留字；表名禁止使用复数名词。 | 强制 | |
| 库名、表名的命名 | 库名尽量与应用名称一致，表名最好用 业务名称_表的作用 命名。 | 强制 | |
| 索引命名 | 主键索引用 pk_字段名；唯一索引用 uk_字段名；普通索引用 idx_字段名。 | 强制 | pk_ 即 primary key；uk_即 unique key；idx_即 index |
| 小数类型 | 数据类型是 decimal，禁止使用 float 和 double，float 和 double 存在精度损失，如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数并分开存储。 | 强制 | |
| varchar类型 | varchar是可变长字符串，不预先分配存储空间，长度不要超过5000个字符，如果长度大于5000应用text（独立出一张表来，用主键来对应，避免影响其他字段的索引效率）。 | 强制 | |
| 表名必备三字段 | id（数据类型是 unsigned bigint，单表递增，步长为1），gmt_create、gmt_modified（主动创建时间、被动更新时间，数据类型都是 datetime）。 | 强制 | |
| 字段冗余 | 字段允许适当冗余，但必须考虑数据一致，冗余字段应具备1）不频繁修改；2）不是varchar超长字段，更不能是text字段。 | 推荐 | |
| 分库分表 | 单表行数超过500万行或者单表容量超过2GB时，才推荐分库分表。 | 推荐 |
设置合适的字符存储长度，不但可以节约数据库表空间和索引存储，更重要的是能够提升检索速度。
3.建索引铁律
| - | 铁律 | Level | 备注 |
|---|---|---|---|
| 唯一索引 | 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。虽然唯一索引影响了 insert 速度，这个损耗可以忽略，但是明显提高了查询速度；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。 | 强制 | |
| join | 超过三个表禁止 join，需要 join 的字段，数据类型必须一致；当多表关联查询时，保证被关联的字段需要有索引；即使双表 join 也要注意表索引、SQL 性能。 | 强制 | |
| varchar字段上建立索引 | 必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。索引长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90% 以上，可以使用 count(distinct left(列名, 索引长度))/count(*) 的区分度来确定。 | 强制 | |
| 页面搜索禁止模糊 | 页面搜索禁止左模糊或者全模糊，如果有需要请走搜索引擎来解决。禁止原因：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。 | 强制 | |
| order by | 如果有 order by 的场景，请注意索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。正例：where a=? and b=? order by c; 索引应建为 a_b_c；反例：索引中有范围查找，那么索引有序性无法利用，如 where a>10 order by b; 索引 a_b 无法排序。 | 推荐 |
4.写SQL铁律
| - | 铁律 | Level | 备注 |
|---|---|---|---|
| count(*) | 不要使用 count(列名) 或 count(常量) 来替代 count(*)，count(*) 是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。count(*) 会统计值为 NULL 的行，而 count(列名) 不会统计此列为 NULL 的行。 | 强制 | |
| count(distinct col) | 计算该列除 NULL 外的不重复行数。注意，count(distinct col1, col2)，如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。 | 强制 | |
| sum(col) | 当一列的值全为 NULL 时，count(col) 的返回结果为 0，但 sum(col) 的返回结果为 NULL，因此使用 sum() 时需要注意 NPE 问题。可用如下方式避免 NPE 问题：select if(isnull(sum(g)), 0, sum(g)) from table; | 强制 | |
| isnull | 使用 isnull() 来判断是否为 NULL 值。NULL 与任何值的比较都为 NULL。 | 强制 | |
| 分页查询逻辑 | 若 count 为 0 应直接返回，避免执行后面的分页语句。 | 强制 | |
| 外键与级联 | 禁止使用外键与级联，一切外键概念必须在应用层解决。原因：外键与级联不适合分布式、高并发集群，级联更新是强阻塞，存在数据库更新风暴的风险，外键影响数据库的插入速度。 | 强制 | |
| 存储过程 | 禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。 | 强制 | |
| 数据订正 | 数据订正（特别是删除、修改记录操作）时要先 select，避免出现误删除，确认无误后才能执行更新语句。 | 强制 | |
| in | in 操作能避免就避免，如果实在避免不了，in 后面的集合元素数量要控制在 1000 个以内。 | 推荐 | |
| truncate table | 禁止使用 truncate table，truncate table 比 delete 速度快，且使用的系统和日志资源少，但是 truncate 无事务且不触发 trigger，有可能造成事故，故不要在开发代码中使用此语句。 | 参考 |
5.ORM映射铁律
| - | 铁律 | Level | 备注 |
|---|---|---|---|
| 表查询 | 禁止使用 * 作为查询的字段列表，需要哪些字段必须明确。 | 强制 | |
| POJO | POJO 类的布尔属性不能加 is，而数据库字段必须加 is，要求在 resultMap 中进行字段与属性之间的映射。 | 强制 | |
| 返回参数 | 禁止用 resultClass 作为返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个属性与之对应。原因：配置映射关系，使字段与 DO 类结耦，方便维护。 | 强制 | |
| 返回参数 | 禁止直接使用 HashMap、HashTable 作为查询结果集的输出。原因：属性值的类型不可控。 | 强制 | |
| sql.xml 配置参数 | sql.xml 配置参数使用 #{}, #param#，不要使用 ${}，${} 容易出现SQL注入。 | 强制 | |
| queryForList | 禁止使用 Mybatis 自带的 queryForList(String statementName, int start, int size)。原因：其实现方式是在数据库取到 statementName 对应的 SQL 语句的所有记录，再通过 subList 取 start, size 的子集合。 | 强制 | |
| 更新时间 | 更新数据库表记录时，必须同时更新记录对应的修改时间。 | 强制 | |
| 更新数据库表记录 | 不要写一个大而全的数据更新接口（传入为 POJO 类）。执行 SQL 时，不要更新无改动的字段，原因：容易出错、效率低、增加 binlog 存储。 | 推荐 | |
| @Transactional | @Transactional 事务不要滥用。事务会影响数据库的 QPS。另外，使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。 | 参考 | |
| Mybatis 动态sql标签 | < isEqual> 中的 compareValue 是与属性值对比的常量，一般是数字，表示相等时执行相应的 SQL 语句；< isNotEmpty> 表示不为空且不为 null 时执行；< isNotNull> 表示不为 null 时执行。 | 参考 |
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
相关文章
在使用mysql多表联合查询时怎样可以做到只返回返回一张表的内容，本文将详细介绍，需要了解的朋友可以参考下2012-12-12
在讲MySQL的Join语法前还是先回顾一下联结的语法，呵呵，其实连我自己都忘得差不多了，那就大家一起温习吧，这里我有个比较简便的记忆方法，内外联结的区别是内联结将去除所有不符合条件的记录，而外联结则保留其中部分。外左联结与外右联结的区别在于如果用A左联结B则A中所有记录都会保留在结果中，此时B中只有符合联结条件的记录，而右联结相反，这样也就不会混淆了。2014-05-05
Navicat Premium15连接云服务器中的数据库问题及遇到坑
这篇文章主要介绍了Navicat Premium15连接云服务器中的数据库问题及遇到坑，本文通过图文并茂的形式给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2021-03-03
下面小编就为大家带来一篇mysql的sql语句特殊处理语句总结(必看)。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧2017-03-03
这篇文章主要介绍了关于MySQL注入时绕开过滤的技巧，文中通过图文与示例代码介绍的很详细，需要的朋友可以参考借鉴，下面来一起看看吧。2017-02-02
这篇文章主要介绍了mysql查询获得两个时间的时间差方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2022-05-05
Windows下MySQL 8.0.29 安装和删除图文教程
这篇文章主要为大家详细介绍了Windows下MySQL 8.0.29 安装和删除图文教程，文中安装步骤介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2022-07-07
在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,一般都是通过主从复制的方式来同步数据,再通过读写分离（来提升数据库的并发负载能力,这篇文章主要给大家介绍了关于MySQL主从复制与读写分离的相关资料,需要的朋友可以参考下2021-11-11
MySQL中的count(*) 和 count(1) 区别性能对比分析
这篇文章主要介绍了MySQL中的count(*)和count(1)区别性能对比，本节还介绍了我们常说的索引下推，结合实例代码给大家介绍的非常详细,需要的朋友可以参考下2023-05-05
MySQL Workbench是一个强大的数据库设计工具,提供了便捷的数据导入导出功能,本文就来介绍一下MySQL Workbench导出表结构与数据的实现步骤,感兴趣的可以了解一下2024-05-05
最新评论