Unity3D连接MySQL完整指南：从环境搭建到异步查询避坑实战

很多Unity开发者做到一定阶段都会遇到同一个问题：项目需要一个真正的数据库，而不是把数据塞进PlayerPrefs或者本地JSON文件。我自己是在做一个跨端小游戏项目时被逼着去搞Unity3D连接MySQL的，当时排行榜、用户存档、活动配置全都要从服务器拉，本地文件方案根本撑不住。折腾了几天，踩了各种坑之后，我把整套流程和排查思路完整整理了出来，这篇东西应该能帮你少走很多弯路。无论你是刚接触数据库的新手，还是已经用PlayerPrefs顶了很长时间的独立开发者，看完都能直接上手。照着做，大概一个下午就能在你的Unity项目里跑通MySQL的读写。

1. 为什么非要在Unity里接MySQL——适用场景与选型思考

1.1 从数据存PlayerPrefs说起

先说个真实场景。我做过一个多人小游戏，最初为了省事，所有玩家数据都存PlayerPrefs。单机测试没问题，一旦上了真机、多设备登录，问题全冒出来了：换设备存档没了、排行榜数据对不上、运营想改活动配置只能发版。这个阶段我意识到，必须在游戏端直接连一个真正的数据库。

很多人的第一反应是"Unity小项目用不上MySQL，太重了"。这个想法对了一半。纯单机、无网络、无账号体系的小游戏确实不需要，但以下情况基本绕不开：

• 排行榜、对战记录等需要跨玩家共享的数据；
• 玩家在不同设备上的存档同步；
• 运营配置（活动开关、道具价格、公告）不希望每次改都要重新发包；
• 需要对数据做统计分析，而不仅仅是"读出来显示"。

这时候MySQL是一个足够成熟、资料丰富、部署灵活的方案。和SQLite相比，MySQL天然支持多客户端并发写，SQLite在并发写场景下很容易遇到锁问题。如果你的游戏是纯本地单机，SQLite确实更轻；但只要有联网和多人需求，MySQL几乎是成本最低的选择。

1.2 直接连MySQL和走后端API怎么选

这里必须说一个经常被吐槽的误区：很多教程一上来就教你在Unity客户端里拼SQL语句直连MySQL，完全不提有没有安全风险。实际项目中你需要区分两种情况：

• 原型验证、内部工具、数据量小且不涉及敏感数据的场景——直接连，快、省事；
• 正式商业项目——通常建议客户端经过后端HTTP接口读写数据，数据库只对后端开放。

但直连MySQL仍然是每个Unity开发者应该掌握的技术，原因有三点：第一，很多原型验证阶段直连最快，能帮你快速验证玩法；第二，开发期用直连调试数据比走后端接口方便太多；第三，很多内部工具、编辑器扩展本身就是直接操作数据库的。所以学会它，不代表你一定在正式环境用它，但用到时你会有底气。

1.3 技术栈和性能预期

在动手之前，先明确一下这套方案的技术边界。Unity端使用C#，通过MySQL官方提供的Connector/NET驱动（即MySql.Data）来访问MySQL数据库。Unity 2018.3以上版本都支持.NET 4.x脚本运行时，这是使用MySQL驱动的基础。数据库端使用MySQL 8.x，这是目前的稳定主线版本。

性能方面要有一个合理的预期：Unity端直连MySQL的网络开销是毫秒级到几十毫秒级不等，取决于网络环境。如果数据库和目标玩家在同一个局域网（比如线下活动的现场排行榜），体验很流畅；如果走公网，就必须考虑异步加载和超时策略，这些问题我在后面会专门展开。

2. 环境准备：从零装好MySQL 8.0并备好可视化工具

2.1 MySQL Server安装与基础配置

网上MySQL安装教程非常多，但很多人装完连不上，问题往往出在几个细节上。先讲标准流程，再提醒几个容易忽略的点。

第一步：下载安装包。

到MySQL官网下载MySQL Community Server。Windows用户注意选择MSI Installer版本，安装过程会引导配置。macOS用户可以用DMG安装包，也可以直接用Homebrew安装，命令是：

bash复制brew install mysql

第二步：安装过程中的关键配置。

• 端口默认3306，除非你明确知道要改，否则保持默认；
• 认证方式在安装时会让你选，这里先记住选"Use Legacy Authentication"或者后面再去改，因为MySQL 8.0默认的caching_sha2_password认证方式会让老版本的Connector/NET连不上（我后面专门讲这个坑）；
• Root密码务必记牢，后面所有操作都离不开它。

第三步：启动并验证。

Windows服务安装完成后，打开cmd或者PowerShell，执行：

bash复制mysql -u root -p

输入刚才设置的root密码，能进到mysql>提示符说明Server装好了。

提示：很多人在这一步卡住，提示"mysql不是内部或外部命令"。这是环境变量没配好。Windows系统需要把MySQL的bin目录（比如C:\Program Files\MySQL\MySQL Server 8.0\bin）加到系统PATH里。macOS/Linux通常不用额外配。

2.2 可视化工具：Workbench还是Navicat

装完Server之后，强烈建议再装一个可视化工具，否则每次都要敲命令行建表查数据，效率太低了。两套主流的方案：

• MySQL Workbench：官方免费，功能够用，安装包在装MySQL Server时就可以勾选。优点是不用额外找破解，缺点是界面略显笨重，但胜在稳。
• Navicat for MySQL：商用工具，界面更友好，导入导出、数据同步、ER图这些功能更省心。适合日常频繁操作数据库的人。

我自己是主力用Navicat，偶尔用Workbench。对于新手，我更推荐先从Workbench上手，免费且踩坑资料多。无论用哪个，核心操作都一样：连上Server，建库，建表，写SQL，然后执行。工具只是外壳，SQL基本功才是内核。

2.3 创建游戏库、专用账号和测试表

这里我强烈建议一个实践：不要用root账号去连Unity项目。root权限太大，万一客户端连接串泄露，整个数据库都暴露了。应该为项目创建一个专用账号，只给最小权限。

打开Workbench，连上Server，执行以下SQL：

sql复制-- 创建项目数据库
CREATE DATABASE IF NOT EXISTS game_db DEFAULT CHARACTER SET utf8mb4;

-- 创建专用账号，只允许从任意主机连接（按需调整）
CREATE USER 'game_user'@'%' IDENTIFIED BY 'your_strong_password';

-- 授权：只给game_db的所有权限
GRANT ALL PRIVILEGES ON game_db.* TO 'game_user'@'%';

-- 刷新权限
FLUSH PRIVILEGES;

utf8mb4这个字符集一定要用，它能完整支持emoji和生僻字。之前有人用默认的utf8，玩家昵称里带个emoji直接写入失败，查了半天才发现是字符集问题。

然后创建一张最基础的玩家表，后面测试就用它：

sql复制USE game_db;

CREATE TABLE player (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(64) NOT NULL,
    level INT DEFAULT 1,
    score INT DEFAULT 0,
    last_login DATETIME
);

顺带说一个和热搜词"mysql中int+5"相关的小细节：MySQL的INT类型是32位整数，上限是2147483647，如果玩家分数会超过这个数，就要考虑BIGINT。存时间戳就用DATETIME或者BIGINT，各有利弊，DATETIME可读性好，BIGINT在排序和时区处理上更省心。我个人的习惯是游戏业务里统一用DATETIME，方便排查问题。

2.4 验证专用账号能否正常连接

在命令行换个账号试试，确认账号没问题：

bash复制mysql -u game_user -p game_db

能进到mysql>说明账号和权限都没问题。这一步千万别省，因为Unity连不上时，排除账号问题能节省大量时间。

3. 核心实现：C#连接MySQL的完整代码与DLL配置

3.1 引入MySql.Data：DLL方案与UPM方案

Unity项目里使用MySQL，首先需要一个C#能调用的MySQL驱动。最常用的就是MySQL官方提供的Connector/NET，解压后找到bin目录下的MySql.Data.dll。

引入方式有两种：

方式一：直接放DLL（最常用）

在Unity项目中创建Assets/Plugins目录，把MySql.Data.dll复制进去。Unity会自动识别并打包。需要注意，MySql.Data.dll有.NET Framework版本和.NET Standard版本的区分，建议使用.NET Standard 2.0版本，兼容性最好。

注意：如果用的是Unity 2018之前的版本，默认是.NET 3.5等价级别，需要到Player Settings里把Scripting Runtime Version切到.NET 4.x Equivalent。现在的Unity版本一般都默认4.x了，但版本太老的项目要检查一下。

方式二：通过UPM包管理

某些版本的MySql.Data可以通过Unity Package Manager安装，或者你自己写一个package.json指向本地包目录。这种方式适合团队协作，但对大多数项目来说，直接放DLL最简单直接。

3.2 最小可用的连接与增删改查

先把最核心的代码贴出来。这是我在项目里封装的MySQLHelper简化版，麻雀虽小五脏俱全：

csharp复制using System;
using MySql.Data.MySqlClient;
using UnityEngine;

public class MySqlHelper
{
    private string _connectionString;

    public MySqlHelper(string server, string database, string userId, string password, int port = 3306)
    {
        _connectionString = $"Server={server};Port={port};Database={database};Uid={userId};Pwd={password};CharSet=utf8mb4;SslMode=None;";
    }

    // 查询，返回DataTable
    public System.Data.DataTable Query(string sql)
    {
        var dt = new System.Data.DataTable();
        using (var conn = new MySqlConnection(_connectionString))
        {
            conn.Open();
            using (var cmd = new MySqlCommand(sql, conn))
            {
                using (var adapter = new MySqlDataAdapter(cmd))
                {
                    adapter.Fill(dt);
                }
            }
        }
        return dt;
    }

    // 执行非查询SQL（增删改），返回影响行数
    public int Execute(string sql)
    {
        using (var conn = new MySqlConnection(_connectionString))
        {
            conn.Open();
            using (var cmd = new MySqlCommand(sql, conn))
            {
                return cmd.ExecuteNonQuery();
            }
        }
    }
}

这里有几个关键点值得展开讲：

连接字符串的细节

• SslMode=None：默认MySQL 8.0驱动会尝试SSL加密连接，如果服务器没配SSL或证书不受信任，连接会失败。本地开发/局域网开发直接设成None最省心。线上环境如果有条件，建议开启SSL，但那是另一个话题。
• CharSet=utf8mb4：和建库时的字符集保持对应，避免中文乱码。
• Pooling=true：这个参数默认是开着的，别关。连接池能显著减少频繁连接的握手开销。

为什么用using

MySqlConnection、MySqlCommand、MySqlDataAdapter这些类型都实现了IDisposable，用using包裹能确保连接、命令、适配器在跳出代码块后被正确释放。如果不释放，连接池里的连接会一直被占用，达到上限之后新连接全部排队，表现就是"跑着跑着突然卡住"，而且很难排查。

查询一个玩家信息测试：

csharp复制public PlayerInfo LoadPlayer(string username)
{
    var helper = new MySqlHelper("localhost", "game_db", "game_user", "your_password");
    string sql = $"SELECT id, username, level, score FROM player WHERE username = '{username}'";
    var dt = helper.Query(sql);

    if (dt.Rows.Count == 0) return null;

    var row = dt.Rows[0];
    var player = new PlayerInfo();
    player.id = Convert.ToInt32(row["id"]);
    player.username = row["username"].ToString();
    player.level = Convert.ToInt32(row["level"]);
    player.score = Convert.ToInt32(row["score"]);
    return player;
}

3.3 从DataTable到游戏对象：两种数据读取方式

上面代码用的是MySqlDataAdapter填充DataTable，这种做法简单直观，适合数据量小、一次性读取的场景。还有一种更贴近底层的方式，用MySqlDataReader逐行流式读取：

csharp复制public List<PlayerInfo> LoadRankList(int topN)
{
    var list = new List<PlayerInfo>();
    string sql = $"SELECT id, username, level, score FROM player ORDER BY score DESC LIMIT {topN};";

    using (var conn = new MySqlConnection(_connectionString))
    {
        conn.Open();
        using (var cmd = new MySqlCommand(sql, conn))
        using (var reader = cmd.ExecuteReader())
        {
            while (reader.Read())
            {
                var p = new PlayerInfo();
                p.id = reader.GetInt32("id");
                p.username = reader.GetString("username");
                p.level = reader.GetInt32("level");
                p.score = reader.GetInt32("score");
                list.Add(p);
            }
        }
    }
    return list;
}

DataAdapter与DataReader的区别在于，前者是一次性把整个结果集载入内存，后者是边读边取。排行榜只取几十条时差别不大，但如果某个表有上万条数据要批量处理，DataReader明显更省内存，而且速度更快。

3.4 参数化查询：为什么禁止字符串拼接SQL参数

再看前面LoadPlayer的SQL，我是直接用字符串拼接的，这在教学示例里可以，但生产项目里千万不要这么写。原因很简单：SQL注入。用户如果故意在用户名里输入 ' OR '1'='1，拼接出来的SQL就变成了：

sql复制SELECT id, username, level, score FROM player WHERE username = '' OR '1'='1'

这个条件恒为真，会把整张表的数据全部查出来。更危险的是，如果后面还拼接了DELETE、UPDATE语句，结果不堪设想。

正确做法是使用参数化查询：

csharp复制public PlayerInfo LoadPlayer(string username)
{
    string sql = "SELECT id, username, level, score FROM player WHERE username = @username;";
    using (var conn = new MySqlConnection(_connectionString))
    {
        conn.Open();
        using (var cmd = new MySqlCommand(sql, conn))
        {
            cmd.Parameters.AddWithValue("@username", username);
            using (var reader = cmd.ExecuteReader())
            {
                // 读取逻辑
            }
        }
    }
}

参数化查询除了防注入，MySQL还能对同样的SQL模板做缓存优化，频繁执行时性能也比每次拼接不同SQL更好。这个习惯值得从第一天就养成。

提示：Unity里还有一个最常见的坑，就是忘了在代码里处理时间字段。从MySQL读出来的DATETIME在C#里是DateTime类型，直接转字符串会带毫秒甚至时区偏移。建议在SQL查询时就格式化，比如 DATE_FORMAT(last_login, '%Y-%m-%d %H:%i:%s')，或者统一在C#端格式化。

4. 实测中的坑：从64位兼容到认证协议不匹配的完整排查链路

理论上代码写完了，连接字符串配好了，就能跑通了。但实际情况是，没有任何一次接入是顺顺利利的。这一章把我遇到过的坑、网上的高频问题、以及排查问题的完整思路全部列出来。随便中一个都能让你卡上几个小时。

4.1 症状一：编辑器里正常，打包后FileNotFoundException

现象：Unity编辑器里点击Play，所有查询都正常工作。但打包成exe（或Android APK）后，运行到连接数据库的代码，直接抛FileNotFoundException，或者报找不到MySql.Data程序集。

排查过程：

第一步，先确认报错信息里提到的DLL名称。如果是MySql.Data.dll，基本就是插件没正确打包。

第二步，检查Assets/Plugins目录下的DLL Inspector面板。点选MySql.Data.dll，在Inspector里能看到Platform Settings。这里是关键，默认情况下插件会被设置为所有平台都包含，但如果你导入的DLL是64位版本，又在Inspector里勾了Exclude Platforms里的x86，就会导致32位平台下找不到程序集。

第三步，看Unity的日志文件。Windows下打包后的日志在%USERPROFILE%\AppData\LocalLow\公司名\产品名\Player.log，能看到更详细的堆栈信息。

根因：MySql.Data.dll本身是纯C#的托管程序集，与CPU架构无关（理论上AnyCPU都能跑），但Connector/NET的某些版本在初始化时会探测底层Socket实现，如果系统环境缺少某些组件，就会表现为启动时加载失败。更常见的原因其实是打包时Unity没有正确包含这个DLL——很多人在Assets/Plugins下新建了子目录但不小心把DLL的Include Platforms勾选错乱，导致目标平台被排除。

解决方案：

1. 在Assets/Plugins下选中MySql.Data.dll，在Inspector里确认目标平台都被勾选。
2. 如果打包后依然找不到DLL，检查是不是把MySql.Data.dll放在了Assets/Plugins/x86_64这样的子目录中——Unity对子目录的平台归类有特殊逻辑，如果目录名包含平台名，会自动按该平台处理。
3. 最稳妥的做法：在Assets下新建一个普通文件夹（比如Assets/Scripts/DB），把DLL放进去，同时在Player Settings的Scripting Define Symbols里加一行MYSQL_DATA（其实不需要，只是方便排查）。这样Unity会把它当普通托管DLL处理。

4.2 症状二：Authentication method 'caching_sha2_password' not supported

现象：连接字符串、账号密码全对，但连接时抛异常：
Authentication method 'caching_sha2_password' not supported by any of the available plugins

排查过程：

这个错误信息很直接，就是连接器不认MySQL 8.0的默认认证插件。MySQL 8.0默认使用caching_sha2_password，而MySql.Data的旧版本（8.0.11以前，以及很多老教程用的6.x版本）只支持mysql_native_password。

第一步，先查当前用户的认证插件：

sql复制SELECT user, host, plugin FROM mysql.user WHERE user = 'game_user';

如果结果里plugin列是caching_sha2_password，那就实锤了。

根因：认证插件是客户端和服务器在握手阶段协商的协议。老版本连接器只认识mysql_native_password，新服务器默认不认识这个老协议，协商直接失败。

解决方案有两种：

方案A：修改用户认证插件为mysql_native_password

sql复制ALTER USER 'game_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_strong_password';
FLUSH PRIVILEGES;

方案B：升级MySql.Data到8.0.11以上版本，让它支持caching_sha2_password。新版Connector/NET完全支持新认证协议，升级之后问题自动消失。

我的建议是优先方案B，升级驱动版本。因为mysql_native_password在MySQL 8.4里已经开始标记为废弃，未来版本可能移除。能用新驱动就用新驱动，这比改服务器配置更顺应趋势。

4.3 症状三：本地连接超时，但Navicat能连上

现象：Unity里连localhost超时，但Navicat连接一切正常；或者反过来，在编辑器里能连，打包后不能连。

排查过程：

第一步：确认MySQL服务监听地址。在服务器上执行：

bash复制netstat -an | grep 3306

Windows是：

bash复制netstat -an | findstr 3306

如果只监听了127.0.0.1:3306，说明MySQL只允许本机连接，外部设备（比如手机）连不上。此时需要修改配置文件，把bind-address改成0.0.0.0：

ini复制[mysqld]
bind-address = 0.0.0.0

改完重启MySQL服务。

第二步：检查防火墙。Windows防火墙默认会拦截外部对3306端口的访问，需要在防火墙高级设置里添加入站规则，允许TCP 3306。macOS需要在"系统设置-安全性与隐私-防火墙"里开放端口，或者临时关防火墙测试。

第三步：检查连接字符串。如果你在Android真机上用"localhost"连接，那连的是手机自己的3306端口，而不是你电脑的MySQL。Android模拟器连宿主机要用10.0.2.2，真机必须用电脑在局域网里的IP地址（比如192.168.1.100）。这是一个非常高频的低级错误。

csharp复制// Android模拟器
new MySqlHelper("10.0.2.2", "game_db", "game_user", "your_password");

// 局域网真机（用电脑实际IP）
new MySqlHelper("192.168.1.100", "game_db", "game_user", "your_password");

根因：localhost在多数编程环境和数据库客户端里会被解析为IPv6的::1，有时MySQL只监听了IPv4的127.0.0.1，导致IPv6解析后无法连接。所以在连接字符串里，我建议优先用127.0.0.1或者实际IP，尽量不用localhost。

4.4 症状四：编辑器里连得好好的，打包后连不上

这个坑我特别想单独拿出来说，因为它在开发期根本发现不了。

现象：编辑器里Play模式一切正常，数据库读写都没问题。打包成exe在自己电脑上也能跑，但发给朋友测试，他打开游戏什么都加载不出来，日志显示连接超时。

排查过程：

编辑器里能连是因为你的电脑就是数据库所在的机器。打包后的游戏跑到别人电脑上，连接"localhost"连的是玩家自己的电脑，自然没有一个MySQL在等他。

根因：连接字符串里的主机地址写死了localhost或本机IP。真正上线或者给别人测试时，这个地址必须指向你部署数据库的公网服务器或局域网IP。

解决方案：把连接信息从代码里剥离出来，放到可配置的地方。最简单的做法是放在Resources目录下的配置文件里，或者用ScriptableObject管理。更规范的是做一个启动配置界面，支持运行时填服务器地址。实测中，我经常用这样的方式：

csharp复制public class DbConfig : MonoBehaviour
{
    public string server = "your-server-ip";
    public int port = 3306;
    public string database = "game_db";
    public string userId = "game_user";
    public string password = "your_password";

    public string GetConnectionString()
    {
        return $"Server={server};Port={port};Database={database};Uid={userId};Pwd={password};CharSet=utf8mb4;SslMode=None;";
    }
}

然后把DbConfig挂到场景里的某个GameObject上，在Inspector里配置。这样出问题不用重新编译，改完配置就能连上。

4.5 容易被忽略的API差异：.NET Standard 2.0与.NET Framework 4.x

Unity从2018开始支持.NET Standard 2.0和.NET Framework 4.x两套API兼容级别。用MySql.Data时会遇到一个隐藏问题：

某些版本的MySql.Data.dll是针对.NET Framework编译的，在.NET Standard 2.0模式下运行时，会遇到缺少API的问题，比如System.Web相关的依赖。表现就是编译能过，运行到某些方法才崩。

解决方案：在Player Settings -> Other Settings -> Api Compatibility Level里，把.NET Standard 2.0改成.NET Framework。缺点是失去跨平台兼容性，但如果你确定只做PC或只做移动端，用.NET Framework最省心。

如果你的项目确实需要.NET Standard 2.0，那就必须使用MySql.Data的.NET Standard版本DLL（官方NuGet包里有netstandard2.0目录）。这个版本API少了点，但基础功能完全够用。

5. 进阶玩法：异步查询与数据驱动的踩坑心得

5.1 为什么不能在主线程同步查数据库

如果你按上面的代码直接调用helper.Query()，你会发现在游戏运行时会卡一下——数据库查询是阻塞式的，在网络往返期间，Unity主线程被卡住了。数据量小、局域网延时低的时候感觉不强；一旦走公网，哪怕50ms的延迟，配合频繁的查询，游戏画面就会一卡一卡。

这就是为什么真实项目必须在异步上下文中做数据库操作。Unity主线程负责渲染和游戏逻辑，数据库IO应该丢到后台线程去执行，完成后把结果再投递回主线程。

5.2 一个简单的异步查询封装

使用C#的async/await可以优雅解决，前提是你不在Unity的协程里用。下面这个封装是我实际用过的：

csharp复制using System;
using System.Data;
using System.Threading.Tasks;
using MySql.Data.MySqlClient;

public class AsyncMySqlHelper
{
    private string _connectionString;

    public AsyncMySqlHelper(string connectionString)
    {
        _connectionString = connectionString;
    }

    public async Task<DataTable> QueryAsync(string sql, params MySqlParameter[] parameters)
    {
        var dt = new DataTable();
        using (var conn = new MySqlConnection(_connectionString))
        {
            await conn.OpenAsync();
            using (var cmd = new MySqlCommand(sql, conn))
            {
                if (parameters != null)
                    cmd.Parameters.AddRange(parameters);

                using (var reader = await cmd.ExecuteReaderAsync())
                {
                    dt.Load(reader);
                }
            }
        }
        return dt;
    }

    public async Task<int> ExecuteAsync(string sql, params MySqlParameter[] parameters)
    {
        using (var conn = new MySqlConnection(_connectionString))
        {
            await conn.OpenAsync();
            using (var cmd = new MySqlCommand(sql, conn))
            {
                if (parameters != null)
                    cmd.Parameters.AddRange(parameters);

                return await cmd.ExecuteNonQueryAsync();
            }
        }
    }
}

调用方：

csharp复制async void LoadRank()
{
    var helper = new AsyncMySqlHelper(connectionString);
    var sql = "SELECT username, score FROM player ORDER BY score DESC LIMIT 10;";
    var dt = await helper.QueryAsync(sql);
    // 这里已经回到主线程，可以安全操作Unity对象
    foreach (DataRow row in dt.Rows)
    {
        Debug.Log($"{row["username"]} - {row["score"]}");
    }
}

关键点：async void方法里，await之后的部分默认会回到调用时的同步上下文（Unity主线程），所以可以安全操作Unity API。如果你用了ConfigureAwait(false)，执行就不会回到主线程，操作Unity对象会直接报错。这是新手最容易犯的错。

5.3 把查询结果转成Json投递给游戏逻辑

实际项目里不会直接用DataTable去驱动UI，因为DataTable代码太啰嗦了。更常见的做法是先把查询结果转成Json，再反序列化成强类型对象。这样游戏逻辑层不关心数据从哪来，只处理经过验证的C#对象。

从DataTable转Json，我通常直接用Newtonsoft.Json（在Unity里通过com.unity.nuget.newtonsoft-json包安装）：

csharp复制using Newtonsoft.Json;
using System.Data;
using System.Collections.Generic;

public static class DataTableExtensions
{
    public static List<T> ToList<T>(this DataTable dt)
    {
        var json = JsonConvert.SerializeObject(dt);
        return JsonConvert.DeserializeObject<List<T>>(json);
    }
}

DataTable的字段名和列名一致时，转换出来的List能直接绑定到UI。这个扩展方法是我用了很久的组合，比逐个字段读取效率高太多，适合快速开发。

5.4 数据驱动玩法示例

连接MySQL真正价值不光在存档，还在于让运营和策划能直接改数据影响线上游戏。我在一个项目中做过一套配置：每天从MySQL读取活动配置表，控制活动开关、奖励倍数、展示公告。

表结构大概长这样：

sql复制CREATE TABLE activity_config (
    id INT PRIMARY KEY AUTO_INCREMENT,
    activity_name VARCHAR(128),
    is_enabled TINYINT(1) DEFAULT 0,
    reward_multiplier DECIMAL(4,2) DEFAULT 1.0,
    start_time DATETIME,
    end_time DATETIME
);

游戏启动时异步拉取配置：

csharp复制public async Task<List<ActivityConfig>> LoadActivityConfigs()
{
    var helper = new AsyncMySqlHelper(connectionString);
    var dt = await helper.QueryAsync("SELECT * FROM activity_config WHERE is_enabled=1;");
    return dt.ToList<ActivityConfig>();
}

这样策划在数据库里改一行数据，玩家重启游戏后就能看到新活动，不需要发版。类似地，你可以把技能参数、掉落概率、商店价格全部放到数据库里，形成一套数据驱动机制。这个方向再延伸下去，就是大厂的配置中心雏形了。

顺带提一点：现在Unity的热搜词里经常能看到"unity3d通过代码创建animation clips"和"unity3d视频流"，这些都是数据驱动的兄弟玩法：通过运行时数据动态生成动画、动态加载视频流，本质上都是在"用数据控制表现层"。MySQL直连让这些玩法有了一个集中管理的入口。

6. 生产环境还要注意的几件小事

6.1 连接池与断线重连

MySQL驱动默认开启连接池，所以频繁的短连接本身开销不大。但生产环境还有一个问题：如果MySQL服务端因为网络抖动或重启导致连接被断开，客户端持有的连接池里的连接已经失效，下一次使用时就会抛"Unable to connect to any of the specified MySQL hosts"。

解决办法是在执行命令前做一次连接有效性检查，或者捕获到连接丢失异常时主动清空连接池后重试。更优雅的是在连接字符串里加Connection Lifetime=0配合自定义重试逻辑。

6.2 防止数据库拖垮游戏体验

直连MySQL最大的软肋是：客户端直接面对数据库，任何异常都可能暴露到游戏逻辑。我的经验是做好三层防护：

• 超时控制：连接字符串里加Connection Timeout=5;Default Command Timeout=5;，不能让游戏无限等；
• 降级方案：数据库不可用时，从本地缓存（PlayerPrefs或文件）加载上次的数据，保证核心玩法可运行；
• 日志上报：记录每个SQL的执行耗时和错误，方便定位问题。

6.3 最小权限与安全提醒

最后必须再强调一次：正式项目里，客户端直连MySQL通常不建议直接对公网开放。如果只是开发期或局域网工具，那用专用账号 + 强密码 + 最小权限就够了。换到公网场景，强烈建议在中间加一层后端服务，由后端统一管理数据库访问，客户端只走后端API。这不是什么高深理论，而是每一个踩过数据库泄露坑的人的共同教训。

6.4 关于主从、Docker与导入导出

如果你的团队后面用到MySQL主从复制，或者用Docker跑MySQL，也不用慌，因为Unity端连接MySQL的逻辑完全不变——只要服务器地址、账号、数据库名变了而已。主从只是解决"高并发读写"和"高可用"的问题，对应用层是透明的。Docker方式部署MySQL还可以顺带解决环境一致性的问题，如果以后要搭一套测试环境，可以在开发机上快速起一个容器。

对于SolidWorks模型导入Unity3D这种情况，虽然和MySQL没什么关系，但如果你正好要用Unity做一些有数据库交互的工业展示项目，思路也是通用的：模型放心导入，数据交给MySQL，两者各司其职。

从我这次接MySQL的经验来看，最大的感受是：直连数据库本身不复杂，复杂的是在"能用"和"好用"之间做权衡。学会用异步、学会做异常处理、学会把连接信息外部化，才是真正能用在项目里的核心能力。Unity版本从2018到6000.x，MySQL从5.7到8.4，这套基础方案一直成立。先跑通再说优化——这是我一直信奉的准则。