密码须加盐哈希存储，推荐应用层用bcrypt；注册用insert…on duplicate key update配合唯一索引防重复；登录时mysql仅查记录，应用层校验密码；需数据库持久化failed_login_attempts和locked_until防暴力破解。
密码不能明文存数据库，必须用 SHA2() 或 bcrypt 加盐哈希
MySQL 自带的 SHA2() 函数可用，但仅适合简单场景；它不自动加盐，需手动拼接随机 salt（比如用 RAND() 或应用层生成），否则相同密码会生成相同哈希值，易被彩虹表攻击。
更稳妥的做法是在应用层用 bcrypt（如 Python 的 bcrypt.hashpw()、Node.js 的 bcryptjs）处理密码，再把哈希字符串存进 VARCHAR(60) 字段——MySQL 原生不支持 bcrypt 验证，别试图用内置函数模拟。
INSERT ... ON DUPLICATE KEY UPDATE 可防重复注册，但前提是建了唯一索引
用户注册时要校验用户名或邮箱是否已存在，靠应用层先 select 再 INSERT 有竞态风险。直接用 INSERT INTO users (username, email, password_hash) VALUES (?, ?, ?) ON DUPLICATE KEY UPDATE id = id，配合在 username 或 email 字段上建 UNIQUE 索引即可原子化拦截重复。注意：如果用 ON DUPLICATE KEY UPDATE 后没报错，但 ROW_COUNT() 返回 0，说明是重复键触发更新（哪怕什么都没改），这时应返回“用户名已存在”提示。
登录验证必须用 SELECT ... WHERE username = ? AND password_hash = SHA2(?, 256)？不，这是错的
这种写法看似简洁，实则暴露两个严重问题：
• 密码未加盐，SHA2('123456', 256) 永远等于固定字符串，无法抵御预计算攻击
• 把密码哈希逻辑全压给 MySQL，丧失对 bcrypt/scrypt 等强哈希的支持能力
正确做法是：应用层根据用户名查出对应 salt 和哈希值（或直接查 password_hash 字段），再用相同算法重算并比对。MySQL 层只负责按用户名精准查一条记录，不参与密码校验逻辑。
记得给 users 表加 failed_login_attempts 和 locked_until 字段防暴力破解
单纯靠应用层限流不可靠，数据库层需持久化登录失败状态：
• 登录失败时：用 UPDATE users SET failed_login_attempts = failed_login_attempts + 1, locked_until = if(failed_login_attempts >= 4, NOW() + INTERVAL 15 MINUTE, locked_until) WHERE username = ?
• 登录前检查：加 AND (locked_until IS NULL OR locked_until 到查询条件中<br>• 成功登录后：用 <code>UPDATE users SET failed_login_attempts = 0, locked_until = NULL WHERE username = ?
否则攻击者可绕过前端/接口限流，直连数据库反复试探。
实际最难的不是 SQL 写法，而是 salt 存哪、锁定期怎么和应用层时间同步、以及密码重置时如何安全擦除旧哈希——这些都得在业务逻辑里仔细串起来。