Laravel Authentication：跨不同表获取email属性实现登录认证

现有表结构下不需要改表就能实现需求，按以下流程走即可，性能和逻辑正确性都能保证：

• 登录接口统一接收loginId（用户输入的用户名/邮箱二选一值）、password两个参数，不要提前用正则判断loginId是不是邮箱——很多用户会把用户名设成邮箱格式，提前判断很容易出现逻辑误判。
• 先走用户名匹配的快速查询路径：直接查询主user表，SQL参考：

  SELECT ucode, username, password_hash, user_type FROM user WHERE username = ? LIMIT 1
  

  如果查到匹配记录，直接进入密码哈希比对流程，校验通过就签发登录凭证，全程不需要查三张身份表，减少无效IO。
• 如果用户名路径没有查到匹配记录，再走邮箱匹配路径：不要写三表LEFT JOIN的慢查询，分别单表查询三张身份表的email字段，查到匹配结果就立刻终止后续查询，参考逻辑：

  -- 依次查三张表，任意一张查到结果就停止
  SELECT ucode FROM admin WHERE email = ? LIMIT 1
  SELECT ucode FROM teacher WHERE email = ? LIMIT 1
  SELECT ucode FROM student WHERE email = ? LIMIT 1
  

  正常业务逻辑下ucode全局唯一，不会出现同一个邮箱对应多个ucode的情况，如果查到多个匹配结果直接返回账号异常提示即可，避免越权登录。
• 拿到邮箱匹配到的ucode后，反查主user表的用户信息，SQL参考：

  SELECT ucode, username, password_hash, user_type FROM user WHERE ucode = ? LIMIT 1
  

  查到记录后和用户名登录走完全一致的密码校验、凭证签发流程，上层业务不需要区分用户是用用户名还是邮箱登录的。

优化注意事项 #

• 给admin、teacher、student三张表的email字段加唯一索引，一是从数据库层避免同身份下重复邮箱的脏数据，二是大幅提升邮箱字段的查询速度。
• 禁止写主表关联三张身份表的多表JOIN查询做登录匹配，当单表数据量到十万级以上时，这类查询的延迟会明显升高，分表单查命中即返回的性能要高一个数量级。
• 所有密码比对逻辑放在业务代码层做哈希校验，不要把明文密码传到数据库做匹配，避免数据泄露风险。
• 如果后续新增其他用户身份，只需要在邮箱匹配阶段新增对应身份表的查询逻辑即可，不需要改动主登录流程。

内容的提问来源于stack exchange，提问作者Depressedgirlcode