业务级别MySQL

业务级别MySQL

目录

• 业务级别MySQL
  • 1. 权限管理和备份
    • 1. 用户管理
      • 1. SQLyog可视化操作
      • 2. SQL命令操作
  • 2. MySQL备份
  • 3. 规范数据库设计
    • 1. 为什么需要设计
      • 1. 糟糕的数据库设计：
      • 2. 良好的数据库设计
      • 3. 软件开发中，关于数据库的设计
      • 4. 设计数据库的步骤（个人博客）
    • 2. 三大范式
      • 1. 为什么需要数据规范化？
      • 2. 第一范式（1NF）
      • 3. 第二范式（2NF）
      • 4. 第三范式（3NF）
      • 5. 规范性和性能的问题

1. 权限管理和备份

1. 用户管理

1. SQLyog可视化操作

2. SQL命令操作

用户表：mysql下的user表

-- 创建用户
-- create user 用户名 identified by '密码'
create user wang identified by '123456'

-- 修改密码（修改当前用户密码）
-- set password = password('密码')
set password = password('111111')

-- 修改密码（修改指定用户的密码）
-- set password for 用户名 = password('密码')
set password for wang = password('123456')

-- 重命名
-- rename user 原来的用户名 to 新的用户名
rename user wang to wang_2

-- 用户授权：all privileges全部的权限，库，表
-- all privileges：除了给别人授权（grant），其他都能干
grant all privileges on *.* to wang_2

-- 查看权限
show grants for wang_2		-- 查看指定用户的权限
show grants for root@localhost	-- 查看root用户的权限

-- root用户的权限：GRANT PROXY ON ''@'' TO 'root'@'localhost' WITH GRANT OPTION

-- 撤销权限
-- revoke 撤销哪些权限 on 在哪个库撤销 from 给谁撤销
revoke all privileges on *.* from wang_2

-- 删除用户
-- drop user 用户名
drop user wang_2

2. MySQL备份

为什么要备份：

• 保证重要的数据不丢失
• 数据转移

MySQL数据库备份的方式：

1. 直接拷贝物理文件
2. 在SQLyog这种可视化工具中手动导出，在想要导出的表或者库中，选择备份或导出
3. 使用命令行导出：mysqldump

#导出表
# mysqldump -h主机 -u用户名 -p密码 数据库 表名 >物理磁盘位置/文件名
mysqldump -hlocalhost -uroot -p123456 school student >D:/a.sql

# mysqldump -h主机 -u用户名 -p密码 数据库 表名1 表名2 ... >物理磁盘位置/文件名
mysqldump -hlocalhost -uroot -p123456 school student result >D:/a.sql

# 导出数据库
# mysqldump -h主机 -u用户名 -p密码 数据库 >物理磁盘位置/文件名
mysqldump -hlocalhost -uroot -p123456 school >D:/a.sql

# 导入
# 登陆的情况下，切换到指定的数据库
# source 备份文件
source d:/a.sql

# 登陆
mysql -u用户名 -p密码

假设你要备份数据库，防止数据丢失

把整个数据库给别人，sql文件给别人即可

3. 规范数据库设计

1. 为什么需要设计

当数据库比较复杂的时候，我们就需要设计了

1. 糟糕的数据库设计：

• 数据冗余，浪费空间
• 数据库插入和删除都会麻烦、异常（屏蔽使用物理外键）
• 程序的性能差

2. 良好的数据库设计

• 节省内存空间
• 保证数据库的完整性
• 方便我们开发系统

3. 软件开发中，关于数据库的设计

• 分析需求：分析业务的需要处理的数据库的需求
• 概要设计：设计关系图 E-R 图

4. 设计数据库的步骤（个人博客）

• 收集信息，分析需求

  • 用户表（用户登录注销，用户的个人信息，写博客，创建分类）

  • 分类表（文章分类，谁创建的）

  • 文章表（文章的信息）

  • 评论表

  • 友链表（友链信息）

  • 自定义表（系统信息，某个关键的字，或者一些主字段）

• 标识实体（把需求落地到每个字段）

• 标识实体之间的关系

  • 写博客：user --> blog
  • 创建分类：user --> category
  • 关注：user --> user
  • 友链：links
  • 评论：user --> user --> blog

2. 三大范式

1. 为什么需要数据规范化？

• 信息重复
• 更新异常
• 插入异常
  • 无法正常显示信息
• 删除异常
  • 丢失有效的信息

2. 第一范式（1NF）

原子性：保证每一列不可再分

3. 第二范式（2NF）

前提：满足第一范式

每张表只描述一件事情

4. 第三范式（3NF）

前提：满足第一范式和第二范式

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

5. 规范性和性能的问题

关联查询的表不得超过三张表

• 考虑商业化的需求和目标（成本，用户体验） 数据库的性能更加重要
• 在规范性能的问题的时候，需要适当的考虑一下规范性
• 故意给某些表增加一些冗余的字段（从多表查询变为单表查询）
• 故意增加一些计算列（从大数据量降低为小数据量的查询：索引）