应选用TINYINT而非ENUM：TINYINT支持动态扩展状态、避免锁表ALTER，配合状态转移表和日志表（含operator_type、remark等五字段）实现安全、可追溯的状态流转。
商品状态字段该用 TINYINT 还是 ENUM？
用 TINYINT。校园二手场景里，商品状态看似简单（如 pending/onsale/sold），但售后引入“已退款中”“争议处理中”“验机失败”等临时态后，ENUM 每次新增都要 ALTER TABLE ... MODIFY COLUMN status ENUM(...)，线上执行会锁表，且无法做范围查询（比如查所有“非终态”：WHERE status NOT IN (-1, 4, 5)）。TINYINT 配合注释和代码常量即可，例如：COMMENT '0:待审核,1:在售,2:已下单,3:已发货,4:已签收,-1:已下架,-2:退款中,-3:争议中'。
如何防止“已签收”直接跳回“在售”这类非法跳转？
靠应用层校验 + 状态转移配置表，别信 WHERE 条件兜底。建一张 item_status_transitions 表：
CREATE TABLE item_status_transitions ( from_status TINYINT NOT NULL, to_status TINYINT NOT NULL, PRIMARY KEY (from_status, to_status) );
插入合法路径，如 (2,3)（已下单→已发货）、(4,-2)（已签收→退款中）。每次更新前，先查这张表：SELECT 1 FROM item_status_transitions WHERE from_status = ? AND to_status = ?。返回空就拒绝，不走后续任何 DB 操作。硬编码 if-else 在毕业设计或小团队项目里极易漏判，配置表改一行就能放开新流程。
售后操作需要记录谁、为什么、改了什么，日志表怎么设计才不漏信息？
item_status_log 必须包含这五个字段： item_id、from_status、to_status、operator_type（值为 'user' / 'admin' / 'system'）、remark。特别注意：remark 不是可选字段——“买家申请退款”“客服判定责任在卖家”“超时未验机自动关闭”这些语义必须落库，否则查问题时只能猜。索引要建 INDEX idx_item_time (item_id, created_at)，按商品查全生命周期；再加一个 INDEX idx_type_remark (operator_type, remark(100))，方便统计人工干预比例。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
并发场景下，用户点两次“申请退款”导致重复插入日志怎么办？
主表更新和日志插入必须包在同一个事务里，并对主表加行锁。典型写法是：
BEGIN; SELECT * FROM items WHERE id = 123 FOR UPDATE; -- 校验当前状态是否允许跳转 -- 插入 item_status_log -- 更新 items.status COMMIT;
不能分开两个事务，也不能只靠 INSERT ... SELECT 做防重——因为日志表本身没唯一约束，且“同一用户对同一商品多次申请退款”是合法行为（比如撤回后重提）。真正要防的是“同一次操作被触发两次”，行锁 + 应用层幂等 Token（如请求 ID 存 Redis）才是双保险。
状态流转最易被忽略的不是字段类型或 SQL 写法，而是“谁有权限触发哪类变更”。比如学生用户能发起退款，但不能标记“验机失败”；管理员能强制下架，但不能把“已签收”改成“已发货”。这些权限边界必须在应用层拦截，数据库只负责忠实记录结果。
