mysql不直接实现注册逻辑，仅提供users表存储支持；需用唯一索引防重复、bcrypt哈希存密码、先查后插或on duplicate key保证原子性，严禁混用mysql.user。
MySQL 本身不直接实现用户注册系统，它只负责存储和管理用户数据；真正的注册逻辑（表单接收、密码加密、唯一性校验、会话创建等）必须由应用层（如 Python/PHP/Node.js）完成，MySQL 仅提供 users 表结构支撑和必要查询支持。
如何设计安全可用的 users 表
注册系统对数据表的要求不是“能存”，而是“防重复、防泄露、留扩展”。常见错误是直接用 VARCHAR(255) 存明文密码或忽略邮箱唯一性约束。
-
id设为INT UNSIGNED AUTO_INCREMENT PRIMARY KEY，避免负 ID 或手动维护 -
email必须加UNIQUE约束，并设NOT NULL，这是注册去重最可靠依据（用户名可重复，邮箱不能） -
password_hash用CHAR(60)存 bcrypt 哈希值（不是VARCHAR，长度固定），绝不能存明文或简单 MD5 - 加
created_at和updated_at字段，类型用DATETIME DEFAULT CURRENT_TIMESTAMP，便于排查异常注册行为 - 避免用
is_active这类字段做初期注册控制——新用户默认激活更符合 MVP 逻辑；后续需要邮箱验证再加email_verified_at字段
INSERT 时如何避免重复注册报错
应用层不能依赖 MySQL 报错（如 Duplicate entry for key 'email'）来判断邮箱是否已存在，这属于被动防御，体验差且暴露数据库结构。正确做法是先查后插，或用 INSERT ... ON DUPLICATE KEY UPDATE 配合业务逻辑兜底。
- 推荐先执行
SELECT COUNT(*) FROM users WHERE email = ?，查到结果就直接返回「邮箱已被注册」 - 若追求原子性，可用
INSERT INTO users (email, password_hash) VALUES (?, ?) ON DUPLICATE KEY UPDATE id = id，然后检查ROW_COUNT()是否为 1（插入成功）或 0（冲突） - 不要用
REPLACE INTO，它会隐式触发 DELETE + INSERT，在有外键或触发器时可能引发意外副作用
为什么不能用 MySQL 的 USER 表或 CREATE USER 做业务注册
MySQL 自带的 mysql.user 表和 CREATE USER 语句是给数据库权限体系服务的，和业务用户完全无关。混淆二者会导致严重安全问题和维护混乱。
-
CREATE USER 'alice'@'%' IDENTIFIED BY 'pwd';创建的是能连数据库的账号，不是你的网站用户 -
mysql.user表里的密码哈希格式、过期策略、主机限制都面向 DBA 场景，无法对接 Web 登录流程 - 业务用户密码需支持重置、第三方登录映射、多设备登出等，这些必须在应用层实现，数据库只存凭证摘要
真正难的从来不是建表或写 INSERT，而是当并发注册请求打进来时，怎么保证邮箱唯一性不被绕过——这要求应用层加锁或数据库层用唯一索引+事务隔离配合，而很多人只记得加索引，却忘了把注册操作包在 BEGIN ... COMMIT 里。
