SQLite 与 MySQL

选择数据库#

类型	适用场景
SQLite	单服、无需外部数据库、维护成本低
MySQL	希望使用远程数据库和现有备份体系

默认使用 SQLite，文件为 plugins/KaFurnace/furnaces.db。

准备 MySQL#

先在 MySQL 中创建数据库和专用账号：

CREATE DATABASE kafurnace CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'kafurnace'@'%' IDENTIFIED BY 'replace-with-a-strong-password';
GRANT ALL PRIVILEGES ON kafurnace.* TO 'kafurnace'@'%';
FLUSH PRIVILEGES;

然后填写 database.mysql 并把 database.type 改为 mysql，最后重启服务器。插件会自动创建 virtual_furnaces 表。

远程生产库应使用默认的 sslMode=VERIFY_IDENTITY 并提供受信任证书。只有同机、隔离的临时测试库可以把参数改为 sslMode=DISABLED。默认连接与读取超时较短，数据库故障时关键玩家操作仍可能等待数秒，因此必须在目标网络延迟下测试。

MySQL 支持远程存储，但首版不是多服务器共享状态方案。不要让多个 KaFurnace 实例同时读写同一个库，否则各服务器的内存状态可能互相覆盖。

写入与失败语义#

玩家放入、取出、购买、切换类型、等级升级、永久解锁、自动配送、通知认领和守恒扣除会等待数据库确认；失败时本次领域变更回滚，物品或升级状态不会由正常路径交付。等待期间会占用当前 Bukkit 主线程或 Folia 玩家线程，所以不应把高延迟 MySQL 用作生产后端。

收费事务在扣款后等待上述关键写入。数据库拒绝时会恢复领域状态并尝试原路退款；退款提供者也失败时只能依靠控制台 SEVERE 审计记录人工核对。

普通后台快照按熔炉 ID 合并，且已经确认的新 revision 不会被迟到的旧快照覆盖。完成轮次和燃料消耗会立即排入队列，但强制结束进程仍可能发生在后台写入完成前；checkpoint-seconds 不是事件日志或零数据丢失保证。

SQLite JDBC 与 MySQL Connector/J 在首次使用时由 Libby 下载，并使用插件内固定的 SHA-256 校验。依赖缓存被修改或下载内容不匹配时，插件会拒绝加载该驱动。

切换数据库#

切换类型不会自动搬迁数据。应先确保所有玩家取空虚拟物品，再停服、备份旧数据库、修改配置并启动新后端。

项目发布前的测试数据库不兼容更早的内部测试表；测试新结构时请按约定删除旧测试数据库。当前表同时保存五类等级、三类能力、多槽物品、各输出槽经验、当前加工槽位和通知批次。

备份#

SQLite 应在服务器停止后备份 furnaces.db。MySQL 使用现有的定时备份或 mysqldump 流程。数据库中包含玩家物品，不应只依赖世界备份。