前言

很多Unity开发者第一次接触数据库时都会问：我的游戏数据存本地JSON不行吗？为什么非要搞个MySQL？ 本篇不讲代码，先把”要不要用”和”怎么用才安全”这两个根本问题想清楚，避免后面踩大坑。

一、什么场景必须上数据库？

场景 本地存储够用？ 推荐方案
单机存档/设置 ✅ JSON / PlayerPrefs / SQLite
排行榜/好友系统 ❌ MySQL + HTTP API
账号注册/登录 ❌ MySQL + HTTPS + Token
多人实时同步 ❌ MySQL + WebSocket / Netcode
运营后台管理 ❌ MySQL + Web Admin
DLC/配置热更 ⚠️ CDN优先，DB做版本索引
数据分析/埋点 ❌ MySQL / ClickHouse

💡 核心判断标准：只要数据需要跨设备、跨用户、或持久化到服务端，就必须上数据库。

二、三种主流架构对比

2.1 客户端直连MySQL（仅适合开发/内网工具）

1
[Unity Client] ←→ [MySQL Server]
  • ✅ 开发调试快，无需写后端
  • ❌ 连接字符串暴露密码，SQL可被反编译
  • ❌ 无法做权限控制，任何玩家都能删库
  • ❌ 高并发下连接数爆炸

⚠️ 铁律：生产环境严禁客户端直连MySQL。 仅限Editor工具、内网测试、个人学习使用。

2.2 HTTP API 中间层（推荐绝大多数项目）

1
[Unity Client] → HTTP/HTTPS → [Web API (Node/Go/C#)] → [MySQL]
  • ✅ 密码和SQL永远不离开服务器
  • ✅ 可做鉴权、限流、日志、缓存
  • ✅ 前后端解耦，换数据库不影响客户端
  • ✅ 水平扩展容易

2.3 WebSocket / gRPC 长连接（重度多人游戏）

1
[Unity Client] ↔ WebSocket/gRPC ↔ [Game Server] ↔ [MySQL + Redis]
  • ✅ 实时性极高（帧同步/状态同步）
  • ✅ 二进制协议省带宽
  • ❌ 开发成本高，运维复杂
  • ❌ 不适合纯CRUD业务

选型决策树

1
2
3
4
5
你的项目需要服务端数据吗？
├── 否 → 本地存储(SQLite/JSON)
└── 是 → 有实时对战/聊天需求吗？
    ├── 是 → WebSocket/gRPC + MySQL + Redis
    └── 否 → HTTP API + MySQL（本系列重点）

三、安全五原则（刻在脑子里）

原则 错误做法 ❌ 正确做法 ✅
参数化查询 "WHERE name='" + input + "'" cmd.Parameters.AddWithValue("@name", input)
最小权限 root账号直连 专用只读/读写账号，禁止DROP/GRANT
传输加密 明文HTTP HTTPS + TLS 1.2+
敏感信息外置 密码硬编码在C# ScriptableObject / 环境变量 / Vault
输入校验 信任客户端传参 服务端白名单校验 + 长度限制

🛡️ 记住：客户端的一切数据都不可信。 即使你做了混淆、加密、反注入，攻击者总能找到办法。真正的安全只在服务端。

四、本系列学习路线

篇目 内容 学完能做什么
第1篇（本篇） 架构选型与安全原则 做出正确的技术决策
第2篇 MySQL安装与表结构设计 独立建库建表
第3篇 Unity环境配置与驱动选型 跑通第一个查询
第4篇 增删改查完整实现 封装通用DAO层
第5篇 HTTP API中间层实战 搭建安全的后端服务
第6篇 完整项目实战：玩家管理系统 从0到可部署的全栈Demo

总结

先想清楚架构，再动手写代码。 选对架构比写对代码重要100倍。本篇确立了三个核心认知：①生产环境必须走API中间层；②安全五原则是底线不是建议；③本系列以HTTP API + MySQL为主线。

下一篇我们动手安装MySQL并设计第一张游戏数据表。

系列导航
🏁 本篇为系列首篇
第2篇：MySQL安装与表结构设计 →

说些什么吧！

waline