应使用应用层带盐慢哈希（如bcrypt/Argon2）加密密码并存入mysql，登录时用相同算法比对；必须用参数化查询防SQL注入；登录成功后生成随机session_id存入sessions表关联user_id与过期时间。
用户登录时怎么安全比对密码
MySQL 本身不处理登录逻辑，但必须配合应用层做密码校验。关键点是：永远不要在数据库里存明文密码，也不要用 MD5() 或 SHA1() 这类快速哈希函数直接存密码。
推荐做法是在应用层（如 python/php/node.js）用带盐的慢哈希（如 bcrypt、Argon2）加密密码，再把哈希值存进 MySQL 的 VARCHAR(255) 字段。登录时，应用层读出该哈希值，用相同算法比对用户输入的明文密码。
如果非要在 MySQL 内完成简单验证（仅限测试或极轻量场景），可用 SHA2(password, 256)，但必须加固定盐并避免重放攻击：
select id, username FROM users WHERE username = 'alice' AND password_hash = SHA2(CONCAT('my_salt', 'user_input_password'), 256);⚠️ 注意：password_hash 字段必须预先存的是 SHA2(CONCAT('my_salt', 'real_password'), 256)，且盐值不能暴露给前端。
怎么防止 SQL 注入导致绕过登录
最常见错误是拼接用户输入到 SQL 查询中，比如：
SELECT * FROM users WHERE username = '" + user_input + "' AND password = '" + pass_input + "';一旦用户输入 admin' -- ，整个条件就变成 WHERE username = 'admin' -- ' AND password = ...，注释掉密码校验，直接登录成功。
必须使用参数化查询（Prepared Statements）：
- Python（
mysql-connector-python）：用%s占位，传参列表执行 - PHP（pdo）：用
:username命名占位符，$stmt->execute(['username' => $u]) - Node.js（
mysql2）：用?占位，数组传参
MySQL 服务端不认客户端传来的引号或注释符——参数化之后，输入内容只当数据，不会被解析为语法。
登录状态怎么和 MySQL 关联起来
MySQL 不保存会话，但可以辅助存储会话元数据。典型做法是：用户登录成功后，生成一个随机 session_id（如 UUID v4），写入 sessions 表，并关联 user_id 和过期时间：
CREATE TABLE sessions ( session_id CHAR(36) PRIMARY KEY, user_id INT NOT NULL, expires_at DATETIME NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_expires (user_id, expires_at) );每次请求带 session_id（如 cookie），后端查表确认是否有效、未过期、归属正确用户。注意定期清理过期记录：delete FROM sessions WHERE expires_at
别把敏感字段（如密码、Token 密钥）存在这张表里；也别用 user_id 直接当 session ID——可预测性高，易被撞库。
为什么不能用 SELECT * FROM users WHERE username=’…’ AND password=’…’
这种写法看似直白，但存在多个硬伤：
-
password字段如果存的是哈希值，明文比对永远失败（除非你存的就是明文，这绝对不行） - 没有防暴力破解机制：没限制单位时间尝试次数，没加锁账号逻辑
- 没区分「用户不存在」和「密码错误」，泄露用户名枚举信息
- 没记录登录失败日志，无法审计异常行为
- 没考虑时区、字符集问题：比如用户名含 emoji 或大小写混用，
utf8mb4_bin排序规则才保证精确匹配
真正上线的登录接口，MySQL 只负责“按唯一键取用户数据”和“存会话元数据”，其余逻辑（限流、风控、多因素、日志）全在应用层闭环。数据库不是登录引擎，只是可信的数据协作方。