本文介绍在 mariadb 中通过 union all 实现跨学生、教师表联合查询图书馆访问记录，并准确标注每条记录来源表（students 或 teachers）的实用方案，兼顾已部署库的兼容性与新设计的规范性。
本文介绍在 mariadb 中通过 union all 实现跨学生、教师表联合查询图书馆访问记录，并准确标注每条记录来源表（students 或 teachers）的实用方案，兼顾已部署库的兼容性与新设计的规范性。
在实际业务中，当 library_access 表仅通过 human_id 关联到多个角色实体（如 students 和 teachers），而需一次性查出所有有效访问记录并明确其角色归属时，最直接且符合 SQL 标准的解决方案是使用 UNION ALL 合并两个独立的 JOIN 查询。该方法无需修改现有表结构，完全适配已上线的 MariaDB 5.5 环境，且被 Go 应用层消费时结构清晰、无歧义。
以下是推荐的查询语句：
SELECT
la.access_id,
s.id AS role_id,
'student' AS role_type,
s.group_id AS extra_info
FROM library_access la
INNER JOIN students s ON la.human_id = s.human_id
UNION ALL
SELECT
la.access_id,
t.id AS role_id,
'teacher' AS role_type,
t.academic_degree AS extra_info
FROM library_access la
INNER JOIN teachers t ON la.human_id = t.human_id
ORDER BY access_id;
✅ 关键优势说明：
- UNION ALL 比 UNION 更高效（不执行去重），适用于角色互斥场景（一个 human_id 不会同时存在于 students 和 teachers 表中——若存在此需求，需额外约束或逻辑处理）；
- 显式定义 role_type 字段（如 'student'/'teacher'）比布尔值更语义化、可扩展（未来支持 admin 或 alumni 时只需新增分支）；
- role_id 统一别名为逻辑主键字段，便于 Go 结构体映射（例如 type LibraryAccessWithRole struct { AccessID, RoleID int64; RoleType string }）；
- 可按需选择性包含角色特有字段（如 group_id 或 academic_degree），统一为 extra_info 或保留原名并设为 NULL 以对齐列数（注意：UNION 要求各子查询列数与类型兼容）。
⚠️ 注意事项：
- 若存在某 human_id 在两个角色表中均有记录，当前查询将返回两条结果——这属于业务逻辑问题，应在应用层校验或通过数据库唯一约束（如添加 CHECK 或触发器）预防；
- MariaDB 5.5 不支持 CTE（WITH 子句）和窗口函数，因此避免使用更“现代”的写法，UNION ALL 是最稳妥选择；
- 为提升性能，建议在 students(human_id)、teachers(human_id) 及 library_access(human_id) 上建立索引（当前 DDL 中 students.human_id 和 teachers.human_id 已声明为 UNIQUE KEY，但 library_access.human_id 缺少索引，强烈建议补充：ALTER TABLE library_access ADD INDEX idx_human_id (human_id);）。
? 长期设计建议（新系统适用）：
若项目尚未上线，更规范的建模方式是引入角色抽象层：
- 创建 roles 表（id, human_id, role_type ENUM('student','teacher'), role_ref_id）；
- 将 students.id 和 teachers.id 作为 role_ref_id 值存入，统一管理角色归属；
- 查询时单表 JOIN 即可，彻底规避 UNION 复杂度。
但该重构对已有系统成本较高，故对已部署环境，UNION ALL 方案既是最佳实践，也是最务实的选择。
