用户登录时怎么安全比对密码
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 只负责“按唯一键取用户数据”和“存会话元数据”，其余逻辑（限流、风控、多因素、日志）全在应用层闭环。数据库不是登录引擎，只是可信的数据协作方。
