MySQL如何设计数据库
⼀、范式和反范式
优秀的库表设计是⾼性能数据库的基础。如何才能设计出⾼性能的库表结构呢？这⾥必须要提到数据库范式。范式是基础规范，反范式是针对性设计。
1.1、范式
范式是设计数据库结构过程中所要遵循的规则和指导⽅法
其实范式有很多，⽬前有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、(4NF）和
（5NF，⼜称完美范式）。满⾜最低要求的范式是第⼀范式（1NF）。在第⼀范式的基础上进⼀步满⾜更多规范要求的称为第⼆范式
（2NF），其余范式以次类推。⼀般来说，数据库只需满⾜第三范式(3NF）就⾏了。但是⼀般我们就⽤到前三个范式
第⼀范式(确保每列保持原⼦性)
第⼀范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。⽐如某些数据库系统中需要⽤到“地址”这个属性，本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就
⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储，这样在对地址中某⼀部分操作的时候将⾮常⽅便。这样设计才算满⾜了数据库的第⼀范式，如下表所⽰。
上表所⽰的⽤户信息遵循了第⼀范式的要求，这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便，也提⾼了数据库的性能。
第⼆范式(确保表中的每列都和主键相关)
第⼆范式在第⼀范式的基础之上更进⼀层。第⼆范式需要确保数据库表中的每⼀列都和主键相关，⽽不能只与主键的某⼀部分相关（主要针对联合主键⽽⾔）。也就是说在⼀个数据库表中，⼀个表中只能保存⼀种数据，
不可以把多种数据保存在同⼀张数据库表中。
⽐如要设计⼀个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键。
mysql怎么导出数据库给别人第三范式(确保每列都和主键列直接相关,⽽不是间接相关)
第三范式需要确保数据表中的每⼀列数据都和主键直接相关，⽽不能间接相关。
⽐如在设计⼀个订单数据表的时候，可以将客户编号作为⼀个外键和订单表建⽴相应的关系。⽽不可以在订单表中添加关于客户其它信息（⽐如姓名、所属公司等）的字段。
总结：1NF：⽆重复的列，属性不可以拆分（强调列的原⼦性，⽐如家庭电话和个⼈电话需要拆开）
  　2NF：属性完全依赖于主键
  　3NF：属性不传递依赖于其他⾮主属性
1.2、范式的优点缺点
优点：避免数据冗余，减少数据的空间，数据变更速度更快
缺点：范式等级越⾼，表的数量越多，获取数据时表关联过多，性能较差
1.3、反范式
范式设计的表⽆法满⾜性能需求时，需要根据业务场景，在范式的基础上灵活设计
1.业务场景
2.响应时间
3.字段冗余
1.4、反范式和范式的对⽐
⼆、基础规范和命名规范
2.1、基础规范
想要发挥 MySQL 的最佳性能，需要遵循 3 个基本使⽤原则。
1.回归存储的基本职能（MySQL 数据库只⽤于数据的存储，不进⾏数据的复杂计算，不承载业务逻辑，确保存储和计算分离）
2.查询时尽量单表查询，减少跨库查询和多表关联
3.杜绝⼤事务、⼤SQL、⼤批量、⼤字段等性能杀⼿
⼤事务：运⾏步骤较多，涉及的表和字段较多，容易造成资源的争抢，甚⾄形成死锁。⼀旦事务回滚，会导致资源占⽤时间过长。
⼤ SQL：复杂的 SQL 意味着过多的表的关联，MySQL 数据库处理关联超过 3 张表以上的 SQL 时，占⽤资源多，性能低下。
⼤批量：意味着多条 SQL ⼀次性执⾏完成，必须确保进⾏充分的测试，并且在业务低峰时段或者⾮业务时段执⾏。
⼤字段：blob、text 等⼤字段，尽量少⽤。必须要⽤时，尽量与主业务表分离，减少对这类字段的检索和更新。
下⾯具体讲解数据库的基本设置规则：
1. 必须指定默认存储引擎为 InnoDB，并且禁⽤ MyISAM 存储引擎，随着 MySQL 8.0 版本的发布，所有的数据字典表都已经转换成了
InnoDB，MyISAM 存储引擎已成为了历史。
2. 默认字符集 UTF8mb4，以前版本的 UTF8 是 UTF8mb3，未包含个别特殊字符，新版本的 UTF8mb4 包含所有字符，官⽅强烈建议使
⽤此字符集。
3. 关闭区分⼤⼩写功能。设置 lower_case_tables_name=1，即可关闭区分⼤⼩写功能，即⼤写字母 T 和⼩写字母 t ⼀样。
4. 开启 per-table 表空间，开启后，每张业务表会单独创建⼀个独⽴于系统表空间的表空间，便于空间的回收，数据的迁移。
这⾥在实践中有个⼩问题，如何让系统中区分⼤⼩写的库表转换为不区分⼤⼩写的库表呢？因为要修改底层数据，还是⽐较⿇烦的，操作步骤如下：
MySQL dump 导出数据库。
修改参数 lower_case_tables_name=1。
导⼊备份数据时，必须停⽌数据库，停⽌业务，影响⾮常⼤。
禁⽤功能
MySQL 数据库提供的功能很全⾯，但并不是所有的功能性能都⾼效。
存储过程、触发器、视图、event。为了存储计算分离，这类功能尽量在程序中实现。这些功能⾮常不完整，调试、排错、监控都⾮常困难，相关数据字典也不完善，存在潜在的风险。⼀般在⽣产数据库中，禁⽌使⽤。
lob、text、enum、set。这些字段类型，在 MySQL 数据库的检索性能不⾼，很难使⽤索引进⾏优化。如果必须使⽤这些功能，⼀般采取特殊的结构设计，或者与程序结合使⽤其他的字段类型替代。⽐如：set 可以使⽤整型（0，1，2，3）、注释功能和程序的检查功能集合替代。
2.2、命名规范
名称的字符范围为：a-z,0-9和_（下划线）
所有表名⼩写
不允许使⽤-（横杠）、空格
不允许其他字符作为名称例如：@&*%￥#等等
库名：1位数据库类型代码+项⽬简称+识别代码+序号
表名：
字段名：
三、Innodb表要求
主键列，UNSIGNED证书，使⽤auto_increment(这个如果在实际项⽬中不⼀定的，⼤多数不会⽤⾃增，因为在分库分表会有问题，会⽤雪花算法计算id)
必须添加comment注解（主要是为了⽅便他⼈理解）
必须显式指定engine（引擎）
表必备三字段：id,xxx_create,xxx_modified(主键id，创建时间，更新时间)
四、字段设计要求
数据值进⾏参考
合理的类型，最短的长度，NotNULL
表字段少⽽精
单表个数必须控制在2000个以内
单表分表个数必须控制在1024个以内
单表字段数上限控制在20-50
总结
1. 以⾼性能为⽬标，库表设计以范式为主，根据特殊业务场景使⽤反范式，允许必要的空间换时间。
2. 规范数据库的使⽤原则，统⼀规范命名，减少性能隐患，减少隐式转换。
3. ⾼性能表设计的原则：合适的字段、合适的长度、NOT NULL。
4. 从不同⾓度思考 IP、timestamp 的转换，拓宽设计思路。
5. 规范的命名可提⾼可读性，反范式设计可提⾼查询性能。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。