用户登录校验的核心是安全、准确地比对用户输入的账号密码与数据库中存储的信息。MySQL 本身不直接参与应用层的登录逻辑，而是作为凭证存储后端——关键在于如何设计存储结构、加密方式和查询验证流程。
密码不能明文存储
MySQL 表中绝不能以明文保存用户密码。推荐使用强哈希算法（如 bcrypt 或 Argon2）在应用层完成加密，再存入数据库。MySQL 内置的
SHA2()或
MD5()不适合密码存储，因缺乏盐值（salt）且计算过快，易被暴力破解。 注册时：用 bcrypt 对用户密码加盐哈希，将完整哈希字符串（含 salt 和成本因子）存入
password_hash字段 登录时：查出该用户的哈希值，用相同算法重新哈希用户提交的明文密码，再恒定时间比对（避免时序攻击）
账号字段需兼顾唯一性与安全性
建议使用独立的
username或
id作登录凭证，防止枚举风险。若支持多方式登录（如手机号/邮箱），可统一归入一个
login_id字段，并加索引提升查询效率。 建表示例：
CREATE TABLE users (id INT PRIMARY KEY AUTO_INCREMENT, login_id VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, ...);查询语句应只按
login_id精确查找一条记录，避免模糊匹配或 OR 条件拼接（防 SQL 注入）
验证逻辑必须由应用层完成
不要依赖 MySQL 的
WHERE password = SHA2(?, 256)这类写法——这等于把密码哈希逻辑交给数据库，既难控制盐值，又绕过应用层的安全策略（如失败次数限制、IP 封禁）。正确做法是： 先用参数化查询根据
login_id查出用户记录（含
password_hash和状态字段如
is_active） 检查账户是否启用、是否被锁定、是否过期 再用 bcrypt 库比对密码，成功则生成会话（Session / JWT），不成功则记录失败日志并触发风控
补充安全建议
仅靠密码验证远远不够。生产环境应叠加基础防护：
登录接口限流（如 5 次/分钟），防止暴力试探 敏感操作前要求二次验证（短信、邮箱、TOTP） 密码重置链接带短时效签名 token，不用明文密码或 hint MySQL 连接使用最小权限账号（仅 SELECT/INSERT/UPDATE 当前业务表），禁用 root 远程登录
