基于角色的访问控制模型通过用户表、角色表、权限表及关联表实现权限管理，支持灵活的权限校验与扩展。

在MySQL中设计权限控制表时，通常采用基于角色的访问控制（RBAC, Role-Based Access Control）模型。这种模型结构清晰、易于维护和扩展。以下是典型的权限控制表设计思路和具体表结构。

1. 用户表（user）

存储系统用户的基本信息。

CREATE TABLE `user` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT,
  `username` VARCHAR(50) NOT NULL UNIQUE,
  `password` VARCHAR(255) NOT NULL,
  `email` VARCHAR(100),
  `status` TINYINT DEFAULT 1 COMMENT '1:正常, 0:禁用',
  `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

2. 角色表（role）

定义系统中的角色，如管理员、普通用户、编辑等。

CREATE TABLE `role` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT,
  `name` VARCHAR(50) NOT NULL UNIQUE COMMENT '如：admin, editor, viewer',
  `description` VARCHAR(255),
  `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP
);

3. 权限表（permission）

定义具体的权限项，通常是操作级别的控制，比如“用户管理-查看”、“订单管理-删除”。

Intelligent search for agents. Multi-source retrieval with confidence scoring - web, academic, and Tavily in one unified API

智能代理搜索。多源检索置信度评分 - 统一API整合网络、学术和Tavily搜索。

下载

CREATE TABLE `permission` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT,
  `resource` VARCHAR(50) NOT NULL COMMENT '资源名，如 user, order',
  `action` VARCHAR(50) NOT NULL COMMENT '操作名，如 read, create, update, delete',
  `description` VARCHAR(255),
  UNIQUE KEY `uk_resource_action` (`resource`, `action`)
);

4. 用户角色关联表（user_role）

实现用户与角色的多对多关系。

CREATE TABLE `user_role` (
  `user_id` BIGINT,
  `role_id` BIGINT,
  PRIMARY KEY (`user_id`, `role_id`),
  FOREIGN KEY (`user_id`) REFERENCES `user`(`id`) ON DELETE CASCADE,
  FOREIGN KEY (`role_id`) REFERENCES `role`(`id`) ON DELETE CASCADE
);

5. 角色权限关联表（role_permission）

定义角色拥有哪些权限。

CREATE TABLE `role_permission` (
  `role_id` BIGINT,
  `permission_id` BIGINT,
  PRIMARY KEY (`role_id`, `permission_id`),
  FOREIGN KEY (`role_id`) REFERENCES `role`(`id`) ON DELETE CASCADE,
  FOREIGN KEY (`permission_id`) REFERENCES `permission`(`id`) ON DELETE CASCADE
);

权限校验逻辑说明

当用户请求某个接口或操作时，系统按以下流程判断是否有权限：

• 根据用户ID查询其所属的角色（通过 user_role 表）
• 根据角色查询对应的所有权限（通过 role_permission 和 permission 表）
• 检查当前请求的操作（如 resource='order', action='delete'）是否在权限列表中

使用建议

• 权限粒度可根据业务需要调整，可以细化到菜单、按钮级别
• 可增加“数据权限”字段处理不同部门/组织的数据隔离
• 生产环境中 password 应使用强哈希算法（如bcrypt）加密存储
• 考虑加入日志表记录权限变更，便于审计

基本上就这些，这套结构能覆盖大多数Web系统的权限需求，不复杂但足够灵活。