权限管理与备份
用户管理
SQLyog可视化管理
SQL命令操作
用户表:mysql.user
本质:读这张表进行增删改查
-- 创建用户
-- CREATE USER 用户名 IDENTIFIED BY '密码'
CREATE USER LingFeng IDENTIFIED BY '123456'
-- 修改密码(修改当前用户密码)
SET PASSWORD = PASSWORD('123456')
-- 修改密码(修改指定用户密码)
SET PASSWORD FOR LingFeng = PASSWORD('123456')
-- 重命名
-- RENAME USER 原名字 TO 新名字
RENAME USER LingFeng TO LingFeng2
-- 用户授权
-- ALL PRIVILEGES 除了不可以给其他用户授权,所有的权限都可以做
GRANT ALL PRIVILEGES ON *.* TO LingFeng2
-- 查看指定用户的权限
SHOW GRANT FOR LingFeng
-- 查看管理员的权限
SHOW GRANT FOR root@localhost
-- 撤销权限
-- REVOKE 哪些权限 ON 在哪个库撤销 撤销谁
REVOKE ALL PRIVILEGES ON *.* LingFeng2
-- 删除用户
DROP USER LingFeng2
MySQL备份
为什么要备份:
- 保证重要的数据不丢失
- 数据转移
MySQL数据库备份的方式:
-
直接拷贝物理文件
-
在SQLyog这种可视化工具中手动导出
- 在想要导出的表或者库中单击右键选择备份
-
使用命令行导出 mysqldump 命令行中使用
-
导出的格式:
mysqldump -h 主机 -u 用户名 -p 密码 数据库 表名 > 物理磁盘位置/文件名
mysqldump -h 主机 -u 用户名 -p 密码 数据库 表1 表2 表3 …… > 物理磁盘位置/文件名
mysqldump -h 主机 -u 用户名 -p 密码 数据库> 物理磁盘位置/文件名
mysqldump -hlocalhost -uroot -p123456 school student >D:/a.sql
成功的标志
mysqldump: [Warning] Using a password on the command line interface can be insecure.
-
导入的格式:
方式一:
登录的情况下,切换到指定的数据库
source 备份文件
source d:/a.sql
方式二:
mysql -u 用户名 -p 密码 库名< 备份文件
-
规范数据库设计
为什么要设计
当数据库比较复杂的时候,才需要设计
糟糕的数据库设计:
- 数据冗余,浪费空间
- 数据库插入和删除都会很麻烦,可能还会出现异常[屏蔽使用物理外键]
良好的数据库设计:
- 节省内存空间
- 保证数据的完整性
- 方便我们开发系统
软件开发中,关于数据库的设计
- 分析需求:分析业务和需要处理的数据库的需求
- 概要设计:设计关系图E-R图
设计数据库的步骤:(个人博客)
-
收集信息,分析需求
- 用户表(用户登录注销,用户的个人信息,写博客,创建分类)
- 分类表(文章分类,谁创建的)
- 文章表(文章的信息)
- 评论表
- 友链表(友链信息)
- 自定义表(系统信息,某个关键的字,或者一些主字段)
- 说说表(发表心情……id……content……create_time)
-
标识实体(把需求落到每一个字段上面)
-
标识实体之间的关系
- 写博客:user --> blog
- 创建分类:user --> category
- 关注:user --> user
- 友链:links
- 评论:user-user-blog
三大范式
为什么要数据规范化
-
信息重复
-
更新异常
-
插入异常
- 无法正常显示信息
-
删除异常
- 丢失有效信息
三大范式(了解)
第一范式(1NF)
原子性:保证每一列都不可再分
第二范式(2NF)
前提:满足第一范式
每张表只描述一件事情
第三范式(3NF)
前提:满足第一范式和第二范式
确保数据表中的每一列数据都和主键直接相关,而不能间接相关
(规范数据库的设计)
规范性 和 性能的问题
阿里规范:关联查询的表不得超过三张表
- 考虑商业化的需求和目标,(成本,用户体验!)数据库的性能要更加重要一点
- 在规范性能的问题的时候,需要适当的考虑一下规范性
- 故意给某些表增加一些冗余的字段,但是这样可以使得从多表查询变为单表查询,方便许多
- 故意增加一些计算列,从大数据量降低为小数据量的查询,如:索引
规范性 和 性能的问题
阿里规范:关联查询的表不得超过三张表
- 考虑商业化的需求和目标,(成本,用户体验!)数据库的性能要更加重要一点
- 在规范性能的问题的时候,需要适当的考虑一下规范性
- 故意给某些表增加一些冗余的字段,但是这样可以使得从多表查询变为单表查询,方便许多
- 故意增加一些计算列,从大数据量降低为小数据量的查询,如:索引