传奇HERO引擎切换SQL数据库完整配置流程与参数详解教程

传统传奇服务端默认使用DBC2000管理数据库，其本质是PARADOX格式的本地文件数据库。当角色数据量增大、并发登录增多或需要跨区共享账号时，DBC2000的读写瓶颈就会暴露出来。切换到SQL Server数据库是解决这些问题的直接手段。以下以HERO引擎为基础，完整说明从数据库安装到引擎参数修改的全部操作。

## 数据库类型与引擎支持范围

传奇引擎的数据库连接方式分为三种。DBC对应DBC2000的PARADOX文件格式，ODBC通过数据源连接，SQL则直接连接SQL Server等关系型数据库。HERO引擎在DbServer、LoginSrv和Mir200三个组件中都支持SQL连接模式，但需要注意，不管是否使用SQL，M2中使用的物品库、技能库和怪物库仍然调用BDE格式。这意味着StdItems.DB、Magic.DB和Monster.DB这三个文件始终以DBC格式存在，SQL化只针对角色数据、账号数据和行会数据。

GOM引擎默认使用SQL Server，配置入口在DBServer.ini中，通过DBConnectString参数指定连接字符串。GEE引擎和3K引擎的配置逻辑与HERO类似，核心参数名称基本一致。

## SQL Server安装与实例配置

推荐使用SQL Server 2008 R2 Express版，该版本在传奇服务端的兼容性最为稳定。安装时选择默认实例或命名实例均可，如果使用命名实例如SQLEXPRESS，后续配置中服务器名需要写为.\SQLEXPRESS或localhost\SQLEXPRESS，不能只写localhost。

安装完成后需要确认三项设置。第一，SQL Server服务必须处于运行状态，在services.msc中找到MSSQLSERVER或MSSQL$SQLEXPRESS，确保状态为“正在运行”。第二，身份验证模式必须设为混合模式（SQL Server和Windows身份验证），仅Windows身份验证模式下DBC2000和引擎都无法使用sa账户登录。第三，TCP/IP协议必须在SQL Server配置管理器中启用，并确认IPAll下的TCP端口为1433，TCP动态端口留空。

sa账户默认是禁用的，需要用Windows身份验证登录后执行启用语句。打开SQL Server Management Studio，以Windows身份验证连接，新建查询执行：ALTER LOGIN sa ENABLE; 然后执行：ALTER LOGIN sa WITH PASSWORD = '自定义密码'; 密码建议使用字母加数字组合，避免特殊字符导致配置文件解析异常。

## 创建传奇专用数据库

在SQL Server中新建一个数据库，名称建议设为MirDB或与引擎版本对应的名称。数据库的排序规则选择Chinese_PRC_CI_AS，避免角色名排序异常。

创建完成后需要导入表结构。传奇引擎的服务端目录下通常有一个Database文件夹，里面存放.sql脚本文件，包含角色表、账号表、行会表等基础结构。用SQL Server Management Studio打开该脚本，选择MirDB数据库后执行。如果服务端没有自带.sql文件，需要从同引擎版本的完整端中提取，或者手动创建表结构。

账号表的结构需要特别注意。如果用SQL模式管理账号，LoginSrv会直接读写账号表，字段名和类型必须与引擎预期一致。HERO引擎的账号表通常包含Account、Password、LoginTime、LoginIP等字段。如果表结构不匹配，登录时会提示账号不存在或密码错误。

## 引擎配置文件的修改

SQL模式的启用需要在三个配置文件中同时修改，缺一处都会导致启动失败。

第一个文件是DbServer目录下的dbsrc.ini。打开后在[DBSETUP]段中增加或修改以下内容：

```plaintext
DBType=MSSQL
SQLIP=127.0.0.1,1433
SQLUSERNAME=sa
SQLPASSWORD=你的SQL密码
HeroDBName=MirDB
```

SQLIP字段中IP和端口用逗号分隔，本地部署填127.0.0.1,1433。如果SQL Server安装在另一台机器上，填写该机器的内网IP。HeroDBName对应SQL Server中创建的数据库名称，必须完全一致，包括大小写。

第二个文件是LoginSrv目录下的Logsrv.ini。在[DBSETUP]段中增加与dbsrc.ini完全相同的五行配置。LoginSrv负责账号验证，如果这个文件没有配置SQL连接，登录时会仍然走DBC通道，导致账号数据不一致。

第三个文件是Mir200目录下的!setup.txt。同样在[DBSETUP]段中增加相同的配置内容。Mir200是核心游戏逻辑模块，角色数据、行会数据、元宝数据都通过这里读写SQL。

三个文件中的SQLIP、SQLUSERNAME、SQLPASSWORD、HeroDBName必须完全一致。修改完成后保存，不要用记事本另存为UTF-8编码，保持ANSI格式，否则中文字段可能出现乱码。

## 数据迁移与表结构转换

从DBC2000切换到SQL时，已有角色数据需要迁移。DBC2000的数据存储在Mud2\DB目录下的.DB文件中，SQL Server使用完全不同的存储格式，不能直接复制文件。

迁移方式有两种。第一种是使用引擎自带的数据库转换工具，部分HERO引擎版本在DBServer目录下提供DBC转SQL的工具，按提示选择源DB目录和目标SQL数据库即可完成转换。第二种是手动导出导入，用DBC2000打开角色表，导出为CSV或Excel格式，然后在SQL Server Management Studio中使用导入向导将数据导入到对应的SQL表中。手动方式适合角色数据量不大的情况，字段映射需要逐列核对，容易出错。

如果是从零开始搭建，不需要迁移旧数据，直接让引擎在SQL中创建表结构即可。首次启动DbServer时，引擎会检测目标数据库是否存在，如果不存在会自动建表。但账号表和行会表可能需要手动创建，具体取决于引擎版本。

## 启动顺序与连接验证

配置修改完成后，服务端的启动顺序不能乱。正确的顺序是：先启动SQL Server服务，确认服务状态为“正在运行”。然后启动DBServer.exe，观察控制台输出，如果显示“数据库连接成功”或类似提示，说明dbsrc.ini中的SQL配置生效。如果提示连接失败，检查SQLIP、用户名、密码和数据库名，以及SQL Server的TCP/IP协议是否启用。

DBServer启动成功后，再启动LoginSrv.exe和GameSrv.exe。LoginSrv控制台如果显示“登录服务器连接成功”，说明Logsrv.ini中的SQL配置也生效了。最后启动M2Server，在M2控制台中查看是否有数据库相关报错。

一个实用的验证方法是：用GM账号登录游戏，创建一个新角色，然后直接在SQL Server Management Studio中查询角色表，看是否出现了该角色的记录。如果SQL中有记录，说明角色数据已经走SQL通道。

## 一机多区环境下的SQL配置

一机多区时，每个区服需要独立的角色数据库，但账号数据库可以共享。HERO引擎的多区配置中，DBSrv200\dbsrc.ini中的IDSAddr指向主服务器，DBAddr为分服数据库路径。SQL模式下，每个区的dbsrc.ini中HeroDBName设为不同的数据库名，比如MirDB1、MirDB2，而LoginSrv的数据库配置可以指向同一个账号库。

端口规划需要对应调整。一区的登录端口7000，数据库端口6000；二区登录端口7001，数据库端口6001，依次类推。每个区的DbServer使用独立的端口，避免冲突。

资源分配方面，物理内存小于16G的服务器建议不超过3个区同时运行。每个Mir200进程占用2到3G内存，加上SQL Server本身的内存开销，超过3个区容易导致内存不足。

## SQL脚本的批量数据操作

切换到SQL后，可以直接用SQL语句对数据库进行批量修改，这是DBC2000无法高效完成的操作。查询的基本格式是SELECT加查询字段加FROM加目标表加WHERE条件。例如查询所有攻击上限大于3的手镯类装备，指令为：SELECT NAME,PRICE FROM STDITEMS WHERE DC2>3 AND STDMODE=26。

批量修改使用UPDATE语句。例如将所有衣服类装备的价格翻倍：UPDATE STDITEMS SET PRICE=PRICE*2 WHERE STDMODE=10 OR STDMODE=11。执行后显示“SUCCESSFULLY”表示修改成功。

对于角色数据的批量操作，比如全服角色等级提升10级，可以执行：UPDATE CHARACTER SET LEVEL=LEVEL+10 WHERE LEVEL<100。这类操作在DBC2000下需要借助第三方工具逐条修改，SQL模式下一条语句即可完成。

## 常见连接失败与排查

DBC2000连接SQL Server时最常见的报错是“无法连接SQL Server”或“Login failed for user”，原因集中在四个方面。

认证问题方面，确认SQL Server是否启用了混合验证模式，sa账户是否已启用且密码正确。如果sa被锁定或密码过期，执行ALTER LOGIN sa WITH PASSWORD重置。

网络问题方面，检查SQL Server的TCP/IP协议是否启用，1433端口是否被防火墙拦截。在命令行执行telnet 127.0.0.1 1433，如果连接失败说明端口不通。Windows防火墙需要添加入站规则允许TCP 1433。

架构问题方面，DBC2000是32位程序，在64位Windows上必须使用32位ODBC数据源管理器配置。正确路径是C:\Windows\SysWOW64\odbcad32.exe，用这个程序配置系统DSN，而不是用64位的odbcad32.exe。

实例名问题方面，如果SQL Server使用了命名实例，DBC2000中的服务器名要写为.\SQLEXPRESS或localhost\SQLEXPRESS。可以直接填写127.0.0.1,1433绕过命名实例解析。

GOM引擎如果报错chg-server-fail-2，通常是数据库连接超时或表结构不一致导致的，需要比对本地和引擎预期的DB Schema。部分V8内核引擎如果报SQLSTATE[HY000][2003]无法连接MySQL，可以在游戏控制台的配置向导中将账号/角色/个人商店数据库设置为SQLite，而非MySQL。

## 备份与恢复策略

SQL模式下备份比DBC2000更灵活。可以用SQL Server Management Studio创建维护计划，每天定时自动备份MirDB到指定目录。也可以用命令行执行BACKUP DATABASE MirDB TO DISK='D:\Backup\MirDB.bak'，配合Windows任务计划实现无人值守备份。

恢复时在SQL Server Management Studio中右键数据库选择还原，指定备份文件即可。如果只需要恢复部分数据，比如误删了某个行会，可以用查询语句从备份中导出后再导入。

需要注意的是，StdItems.DB、Magic.DB和Monster.DB三个BDE文件不包含在SQL备份范围内，需要单独定期复制Mud2\DB目录。这三个文件虽然不随玩家数据变化，但修改物品属性后如果忘记备份，恢复SQL数据库后物品数据仍然是旧版本。