🔄 切换数据库

1

use database_name;

➕ 创建数据库

1

create database[if not exists] database_name;

🔍 查询数据库

• 查询所有的数据库：

  1	show databases;

• 查询当前正在使用的数据库：

  1	select database();

🗑️ 删除数据库

1

drop database [if exist] database_name

🔐 授权机制

📋 权限类型

• 数据库各部分的授权形式：

  • Read：允许读取数据，但不允许修改数据。
  • Insert：允许插入新数据，但不允许修改现有数据。
  • Update：允许修改数据，但不允许删除数据。
  • Delete：允许删除数据。

• 修改数据库架构的授权形式：

  • Index：允许创建和删除索引。
  • Resource：允许创建新关系。
  • Alteration：允许在关系中添加或删除属性。
  • Drop：允许删除关系。

👤 用户与角色

用户是指可以连接到数据库并执行操作的实体。每个用户有一个唯一的用户名和密码，通过这些凭证来认证和识别该用户。用户具有访问数据库和执行某些操作的权限。通常情况下，用户是直接与权限绑定的。

• 每个用户可以拥有一个或多个权限，这些权限控制用户能在数据库中执行哪些操作（如查询、插入、更新、删除等）。
• 用户可以是数据库的实际操作实体，如开发人员、管理员、应用程序等。

创建用户：

1
2
3
4

create user 'username'@'host' IDENTIFIED BY 'password';
# username：用户名
# host：主机名，'%' 代表任何主机
# password：密码

角色是一种逻辑上的权限集合，它允许将多个权限组合在一起并赋予用户。角色是权限的集合，用户可以通过赋予某个角色来间接获得角色所包含的权限。这样，通过角色管理权限比直接授予权限给用户更简洁和灵活，尤其是当多个用户需要相同权限时。

• 角色是一个权限集合，可以包含多个权限，用户通过赋予角色来获得这些权限。
• 角色并不直接与具体的数据库操作实体（如用户）绑定，而是充当权限的管理和分配工具。

创建角色：

1

create role 'developer';

📜 授权规范

授予权限

代码语法：

1
2
3
4

grant <权限列表> # all privileges表示全部权限
on <视图名/关系名>
to <角色/用户列表>
with grant option # 可选，表示被授予权限的用户／角色可以把得到的权限再授予给另外的用户／角色

注意事项：

• 权限的授予者必须已经拥有指定项目的权限（或者是数据库管理员）。
• 授予对视图的特权并不意味着授予对基础关系的任何特权。
• 默认情况下，被授予权限的用户／角色无权把此权限授予其他用户／角色，除非使用 with grant option 子句。

视图的授权：

• 创建视图的用户不需要获得该视图上的所有权限。他得到的那些权限不会为他提供超越他已有权限的额外授权。例如，如果一个创建视图的用户在用来定义视图的关系上没有 update 权限的话，那么他不能得到视图上的 update 权限。
• 如果用户创建一个视图，而此用户在该视图上不能获得任何权限，系统会拒绝这样的视图创建请求。

模式的授权：

• 默认情况：只有模式的拥有者才能够执行对模式的任何修改，诸如创建或删除关系、增加或删除关系的属性、以及增加或删除索引。
• reference 权限允许用户在创建关系时声明外码。

一个用户/角色的权限：

• 所有直接授予用户／角色的权限。
• 所有授予给用户／角色所拥有角色的权限。

收回权限

代码语法：

1
2
3

revoke <权限列表>
on <视图名/关系名>
from <角色/用户列表>

注意事项：

• 若权限列表中包含 public，所有用户都将失去该权限，但明确授予该权限的用户除外。
• 如果不同的授权者两次向同一用户授予相同的权限，则用户在权限撤销后可以保留该权限。
• 所有依赖于被撤销的权限的权限也将被撤销。
• 收回权限的方式：
  • cascade：级联收回，从一个用户／角色那里收回权限可能导致其他用户／角色也失去该权限。
  • restrict：不需要级联收回。
• 可以收回 grant option。