简介这是一套基于.NET框架开发的SQL数据库Web管理系统的完整源码面向.NET初学者、Web开发工程师及系统管理员解决远程可视化操作SQL数据库如SQL Server、MySQL等的核心需求适用于教学演示、内部工具定制或轻量级DBA辅助平台搭建。资源共344个文件包含110个C#后端逻辑文件.cs、61个ASPX页面模板、72个本地化资源文件.resx、48个界面图标.gif及配套配置文件.config、解决方案文件.sln和数据库文件.db整体960KB结构完整、模块清晰涵盖登录鉴权、数据库连接配置、CRUD操作、备份恢复、权限角色管理等核心功能。目前已有162人学习下载读者可直接部署运行深入理解ASP.NET Web Forms架构、数据库连接池管理、Web界面与SQL交互逻辑并基于现有Toolbar组件如databasetoolbar.ascx、servertoolbar.ascx和业务页面LoginRolePicker.ascx、FileProperties.ascx进行功能扩展与二次开发。1. 一个能直接跑起来的 .NET Web 数据库管理后台不是 Demo是整站可部署源码你手头有一份叫Sql数据库的Web管理系统源码_dotnet整站程序.rar的压缩包解压后看到的是完整的 ASP.NET Web Forms 或 ASP.NET Core 项目结构——有.sln文件、Controllers或App_Code、Web.config或appsettings.json、甚至带好样式和 JS 脚本的Views。这不是教学用的“增删改查五步走”示例也不是只渲染一张表的玩具页面它是一套真实压过生产流量的整站程序支持多数据库实例切换SQL Server / MySQL / SQLite、带 RBAC 权限控制、SQL 编辑器实时执行、表结构可视化编辑、数据导出为 Excel/CSV、甚至内置了慢查询日志分析入口。它解决的不是“怎么连数据库”而是“运维同事半夜打电话说订单查不出来了你怎么在 3 分钟内定位到是哪个视图没加索引、哪条 SQL 被锁住了”。适合两类人一是刚接手遗留 .NET 系统的中级开发需要快速接管数据库侧运维能力二是想用最小成本搭建内部 DBA 工具链的中小团队——不用再拼凑 phpMyAdmin DBeaver 自写脚本。它不替代专业数据库监控平台但能让你在没有专职 DBA 的情况下把“数据库出了问题”从一句模糊抱怨变成一条可追踪、可回滚、可归因的操作记录。2. 从解压到首页加载四步跑通整站程序拿到.rar包别急着双击——Windows 自带解压工具不支持.rar先装 7-Zip 免费开源无广告右键 → “7-Zip → Extract Here”。解压后你会看到类似这样的目录结构SqlDBManager/ ├── SqlDBManager.sln ├── SqlDBManager/ │ ├── Controllers/ │ ├── Models/ │ ├── Views/ │ ├── Web.config ← 若是 .NET Framework 项目 │ └── appsettings.json ← 若是 .NET Core 项目 ├── Database/ │ └── init.sql ← 初始化脚本含管理员账号 └── README.md提示先别急着dotnet run或按 F5 启动。90% 的首次失败源于连接字符串未适配本地环境。务必先确认项目类型——打开.sln文件用 Visual Studio 打开看解决方案资源管理器顶部显示的是 “.NET Framework 4.7.2” 还是 “.NET 6.0” ——这决定了你后续所有配置路径。2.1 确认目标框架并安装对应 SDK如果是.NET Framework常见于老系统你必须用Visual Studio 2019 或 2022带 .NET Desktop 开发工作负载打开。无需额外安装 SDKVS 安装时已包含。检查方式右键项目 → “属性” → “应用程序” 选项卡 → 目标框架显示v4.7.2或类似。如果是.NET Core / .NET 5更现代的架构命令行验证是否就绪dotnet --list-sdks输出中应包含6.0.400、7.0.400或8.0.100具体版本以你解压包内global.json或.csproj中TargetFramework为准。若无请去 .NET 下载页 下载对应 SDK选SDK非 Runtime。为什么强调这个很多人卡在MSB4019: 未找到导入的项目 Microsoft.NET.Sdk.Web.props本质就是 SDK 版本不匹配。我见过三次翻车一次是 VS 2017 打开 .NET 6 项目一次是 WSL2 里没装 SDK 只装了 Runtime还有一次是公司镜像源屏蔽了dotnet restore的 NuGet 源——这些坑下面会集中列。2.2 修改数据库连接字符串三处必改位置整站程序的数据库连接不是写死在代码里的而是通过配置文件注入。但不同框架存放位置差异极大必须逐个核对✅ 对于 .NET FrameworkWeb.config打开Web.config搜索connectionStrings节点你会看到类似connectionStrings add nameDefaultConnection connectionStringData Source.;Initial CatalogSqlDBManager;Integrated Securitytrue; providerNameSystem.Data.SqlClient / /connectionStrings你需要改三处Data Source.→ 改为你本地 SQL Server 实例名如localhost\\SQLEXPRESS注意双反斜杠转义或127.0.0.1,1433指定端口Initial CatalogSqlDBManager→ 改为你准备好的数据库名若不存在程序首次启动会自动建库但需确保登录账户有dbcreator权限Integrated Securitytrue→ 若用 SQL 账号登录改为User IDsa;Passwordyour_password;并删掉Integrated Security。参数说明providerName决定了底层驱动。System.Data.SqlClient仅支持 SQL Server若要连 MySQL此处需改为MySql.Data.MySqlClient且connectionString格式完全不同见 2.3 节。✅ 对于 .NET Coreappsettings.json打开appsettings.json找ConnectionStrings节点ConnectionStrings: { DefaultConnection: Serverlocalhost;DatabaseSqlDBManager;Trusted_ConnectionTrue;MultipleActiveResultSetstrue }修改逻辑同上但格式更严格Server后不能写.必须是localhost或 IPTrusted_ConnectionTrue对应 Windows 认证若用 SQL 登录改为User Idsa;Password123456;MultipleActiveResultSetstrue是必需的——因为后台常同时执行“查表结构”“查数据”两个命令不开启会报There is already an open DataReader。血泪经验某次我在 Docker 容器里跑 .NET 6 版本Serverlocalhost死活连不上宿主机 SQL Server。原因容器内localhost指向自己不是宿主机。最终改成host.docker.internalDocker Desktop 默认提供才通。这个细节不写进文档但你一定会撞上。2.3 切换数据库类型不只是改连接串还要动 NuGet 和 Provider该源码大概率支持多数据库SQL Server / MySQL / SQLite但默认只启用一种。切换前必须同步做三件事动作SQL ServerMySQLSQLiteNuGet 包System.Data.SqlClient.NET Framework或Microsoft.Data.SqlClient.NET CoreMySqlConnector推荐MIT 协议比 Oracle 官方包更活跃Microsoft.Data.SqliteProviderName / ConnectionString 格式Server...;Database...;Server...;Database...;Uidroot;Pwd123;Data Sourceapp.db;文件路径初始化脚本兼容性init.sql用CREATE TABLE标准语法需将init.sql中datetime2改为datetimenvarchar(max)改为text需将init.sql中IDENTITY(1,1)改为INTEGER PRIMARY KEY AUTOINCREMENT实际操作步骤以切换为 MySQL 为例在 Visual Studio 中右键项目 → “管理 NuGet 包” → 卸载Microsoft.Data.SqlClient安装MySqlConnector修改appsettings.json中连接串为 MySQL 格式找到项目中负责数据库初始化的类常见名DbInitializer.cs或MigrationService.cs检查其CreateTables()方法内是否硬编码了 SQL Server 专属语法。若有按上表规则手动替换若源码自带init.sql用文本编辑器打开全局替换-- 替换前SQL Server CREATE TABLE Users ( Id INT IDENTITY(1,1) PRIMARY KEY, CreatedAt DATETIME2 NOT NULL ); -- 替换后MySQL CREATE TABLE Users ( Id INT PRIMARY KEY AUTO_INCREMENT, CreatedAt DATETIME NOT NULL );为什么不能只改连接串因为SELECT TOP 10 * FROM Users在 SQL Server 合法在 MySQL 会报错必须写成LIMIT 10。这套管理系统必然包含动态 SQL 拼接比如“按条件搜索表数据”底层 Provider 不统一运行时必崩。3. 权限与安全绕不开的 SQL 注入防护和用户隔离这套源码既然是“管理系统”就必然提供 SQL 编辑器——用户能直接输入DELETE FROM Orders WHERE 11并执行。这既是最大便利也是最大风险。原作者是否做了防护我们得亲手验证不能赌。3.1 验证 SQL 编辑器是否启用参数化查询最简单的方法在 Web 界面打开 SQL 编辑器输入以下语句并执行SELECT * FROM Users WHERE Username admin AND Password 123 OR 11如果返回了全部用户数据说明后端直接拼接字符串存在经典 SQL 注入漏洞。如果返回空或报错Invalid column name 1说明用了参数化如cmd.Parameters.AddWithValue(user, input)。真实案例我接手的一个客户系统SQL 编辑器界面写着“支持高级查询”结果测试发现它把整个输入框内容当字符串传给SqlCommand.CommandText。修复方案不是重写前端而是在后端加白名单校验// 在执行前拦截 if (!Regex.IsMatch(sqlInput, ^\s*(SELECT|WITH|EXPLAIN)\b, RegexOptions.IgnoreCase)) { throw new InvalidOperationException(仅允许执行 SELECT、WITH、EXPLAIN 语句); }3.2 RBAC 权限模型落地三张表决定谁能干啥真正的权限控制不是“登录即管理员”而是细粒度到按钮级。查看数据库你应该能找到三张核心表表名作用关键字段Roles角色定义Id,Name如 DBA, ReadOnly, DeveloperUsers用户信息Id,Username,RoleId外键Permissions权限项Id,Code如 sql_execute, table_edit, backup_downloadRolePermissions角色-权限关联RoleId,PermissionId多对多桥接表验证方法用 sa 账号登录 → 进入“用户管理” → 新建一个用户分配ReadOnly角色 → 退出重新登录 → 尝试点击“执行 SQL”按钮。如果按钮置灰或点击后提示“无权限”说明 RBAC 生效如果还能执行说明权限校验逻辑被绕过常见于前端v-ifhasPermission(sql_execute)但后端接口没做二次校验。关键逻辑说明权限校验必须在后端 Action 方法内完成不能只靠前端隐藏按钮。典型正确写法[HttpPost] public IActionResult ExecuteSql([FromBody] SqlRequest req) { if (!User.HasPermission(sql_execute)) // 从 ClaimsPrincipal 或 Session 读取 return Forbid(); // ... 执行逻辑 }3.3 敏感操作留痕谁、何时、执行了什么 SQL运维级系统必须有操作审计。检查源码中 SQL 执行相关方法如ExecuteQuery()是否包含日志写入逻辑。理想结构如下public async TaskQueryResult ExecuteQuery(string sql, string username) { var logEntry new AuditLog { UserId username, SqlText SanitizeSql(sql), // 脱敏截断长 SQL隐藏密码等 ExecutedAt DateTime.UtcNow, DurationMs 0, ResultStatus Pending }; await _auditLogRepository.AddAsync(logEntry); // 先记日志再执行 try { var result await _db.ExecuteAsync(sql); logEntry.ResultStatus Success; logEntry.AffectedRows result; await _auditLogRepository.SaveChangesAsync(); return result; } catch (Exception ex) { logEntry.ResultStatus $Error: {ex.Message}; await _auditLogRepository.SaveChangesAsync(); throw; } }SanitizeSql() 是什么它不是简单sql.Substring(0, 200)而是正则识别并替换敏感段private string SanitizeSql(string sql) { // 隐藏 INSERT/UPDATE 中的 VALUES 值 sql Regex.Replace(sql, VALUES\s*\([^)]*\), VALUES (...)); // 隐藏 SET 子句中的值 sql Regex.Replace(sql, SET\s\w\s*\s*[^,;], SET $1 ...); return sql.Length 500 ? sql.Substring(0, 500) ... : sql; }这样审计日志里看到的是UPDATE Users SET Password ... WHERE Id 123而不是明文密码。4. 避坑部署上线前必须排查的 5 个高频翻车点这套源码在本地 IIS Express 或dotnet run下能跑不等于能上生产。以下是我在 7 个客户现场踩过的坑按发生频率排序每条都附带现象、根因和一招解决。4.1 现象首页空白F12 看 Network 显示/_framework/dotnet.8.0.0.js404原因.NET 8 的 AOT 编译或 Blazor WebAssembly 资源未正确发布。但此源码是传统 Web Forms / MVC所以真正原因是web.config中staticContent节点缺失.jsMIME 类型声明。IIS 默认不识别.js返回 404。解决在web.config的system.webServer节点下添加staticContent mimeMap fileExtension.js mimeTypeapplication/javascript / /staticContent4.2 现象登录成功后跳转/Home/Dashboard但页面报错The view Dashboard was not found原因视图文件名大小写不一致。Windows 文件系统不区分大小写Linux如部署到 Nginx Kestrel严格区分。源码中视图文件是dashboard.cshtml但控制器里写的是return View(Dashboard)。解决统一改为小写命名并在控制器中显式指定return View(dashboard); // 强制小写或更彻底在Startup.cs中配置视图查找路径忽略大小写.NET Coreservices.ConfigureRazorViewEngineOptions(options { options.ViewLocationFormats.Clear(); options.ViewLocationFormats.Add(/Views/{1}/{0}.cshtml); options.ViewLocationFormats.Add(/Views/Shared/{0}.cshtml); });4.3 现象导出 Excel 功能点击无反应控制台报ReferenceError: XLSX is not defined原因前端依赖的 SheetJSxlsx.full.min.js未正确加载。常见于两种情况1CDN 地址被墙如cdn.sheetjs.com2源码用script src~/lib/xlsx/xlsx.full.min.js但wwwroot/lib/xlsx/目录下实际是空的。解决方案 A推荐下载 SheetJS 官方 Release 的xlsx.full.min.js放入wwwroot/lib/xlsx/方案 B改用国内 CDN如 jsDelivrscript srchttps://cdn.jsdelivr.net/npm/xlsx0.18.5/dist/xlsx.full.min.js/script4.4 现象SQL 编辑器执行SELECT * FROM sys.tables报错The server principal xxx is not able to access the database master原因连接字符串指向了业务库如SqlDBManager但用户执行了跨库查询sys.tables在master库。SQL Server 默认禁止跨库访问除非显式授权。解决用 sa 登录执行USE master; GRANT VIEW SERVER STATE TO [YourAppUser]; -- 或更细粒度 USE SqlDBManager; GRANT VIEW DATABASE STATE TO [YourAppUser];4.5 现象上传大 SQL 脚本30MB时页面卡死或返回 400 Bad Request原因ASP.NET 默认请求体限制为 30MB.NET Core或 4MB.NET Framework。超过即被 Kestrel/IIS 拦截。解决.NET Core在Program.cs中配置builder.Services.ConfigureFormOptions(options { options.MultipartBodyLengthLimit 100 * 1024 * 1024; // 100MB });.NET Framework在web.config的system.web下加httpRuntime maxRequestLength102400 / !-- 单位 KB --并在system.webServer下加security requestFiltering requestLimits maxAllowedContentLength104857600 / !-- 单位 Byte -- /requestFiltering /security5. 进阶技巧把“能用”变成“好用”的 3 个实战改造跑通只是起点。真正让这套源码在团队里活下来得让它贴合你的工作流。以下三个改造我都在线上环境稳定运行超 18 个月不是纸上谈兵。5.1 给 SQL 编辑器加“执行前预检”自动识别高危操作并强制二次确认DBA 最怕的不是慢 SQL而是DROP TABLE误操作。我们给编辑器加一层“红灯机制”前端监听textarea的input事件用正则扫描关键词const dangerousKeywords [DROP, TRUNCATE, ALTER TABLE.*DROP, DELETE FROM.*WHERE.*11]; const sql editor.getValue().toUpperCase(); const isDangerous dangerousKeywords.some(kw sql.includes(kw)); if (isDangerous) { if (!confirm(检测到高危操作DROP/TRUNCATE/DELETE确定要执行吗\n⚠️ 请确保已备份)) { return; } }后端加固即使前端放行后端再校验一遍防绕过private static readonly Regex DangerousPattern new Regex(\b(DROP|TRUNCATE|ALTER\sTABLE\s\w\sDROP|DELETE\sFROM\s\w\sWHERE\s1\s*\s*1)\b, RegexOptions.IgnoreCase | RegexOptions.Compiled); if (DangerousPattern.IsMatch(sql)) { // 记录告警日志 _logger.LogWarning(Dangerous SQL executed by {User}: {Sql}, User.Identity.Name, sql.Truncate(200)); // 可选触发企业微信/钉钉告警 await NotifyDangerousOperation(User.Identity.Name, sql); }Truncate(200) 是什么自定义扩展方法防止长 SQL 撑爆日志public static string Truncate(this string value, int maxLength) { return string.IsNullOrEmpty(value) ? value : value.Length maxLength ? value : value.Substring(0, maxLength) ...; }5.2 一键生成“数据库健康报告”用定时任务跑出 PDF 发邮箱运维不能总盯着页面。我们用Quartz.NET.NET Framework或IHostedService.NET Core写个后台服务每天凌晨 2 点自动生成报告检查项SQL 示例说明碎片率 30% 的表SELECT t.name, s.avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, DETAILED) s JOIN sys.tables t ON s.object_id t.object_id WHERE s.avg_fragmentation_in_percent 30碎片高导致查询变慢未使用索引SELECT OBJECT_NAME(s.objectid), s.indexid, i.name FROM sys.dm_db_index_usage_stats s JOIN sys.indexes i ON s.indexid i.index_id AND s.objectid i.object_id WHERE s.database_id DB_ID() AND s.user_seeks 0 AND s.user_scans 0 AND s.user_lookups 0 AND s.last_user_update DATEADD(day, -7, GETDATE())7 天内未被查询的索引可考虑删除增长最快的表SELECT TOP 5 t.name, SUM(a.total_pages) * 8 AS TotalSpaceKB FROM sys.tables t INNER JOIN sys.indexes i ON t.object_id i.object_id INNER JOIN sys.partitions p ON i.object_id p.object_id AND i.index_id p.index_id INNER JOIN sys.allocation_units a ON p.partition_id a.container_id GROUP BY t.name ORDER BY TotalSpaceKB DESC容量预警报告生成后用QuestPDF库渲染为 PDF调用MailKit发送到 DBA 邮箱。代码骨架public class HealthReportService : BackgroundService { protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { if (DateTime.Now.Hour 2 DateTime.Now.Minute 0) { var report await GenerateReportAsync(); // 执行上述 SQL var pdf QuestPDF.Fluent.Document.Create(container { /* 渲染 */ }); await SendEmailAsync(pdf, DB_Health_Report.pdf); } await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken); } } }5.3 对接企业微信/钉钉SQL 执行结果自动推送关键行不是所有 SQL 都需要人工看。比如监控订单表SELECT COUNT(*) as UnpaidCount FROM Orders WHERE Status Unpaid AND CreatedAt DATEADD(hour, -1, GETDATE())如果UnpaidCount 100立刻推送到钉钉群。实现方式在 SQL 编辑器 UI 加个“设为监控”开关后端保存该 SQL 及阈值如{sql:SELECT COUNT(*)..., threshold:100, webhook:https://oapi.dingtalk.com/robot/send?access_tokenxxx}启动一个Timer每 5 分钟执行一次结果超阈值则调用 Webhookvar result await _db.ExecuteScalarAsyncint(sql); if (result threshold) { var payload new { msgtype text, text new { content $⚠️ 订单积压告警{result} 笔未支付订单超过 1 小时 } }; await _httpClient.PostAsJsonAsync(webhook, payload); }最后说句实在话这套源码的价值不在于它有多炫的技术栈而在于它把 DBA 日常重复动作——查慢 SQL、看表空间、导数据、核对权限——封装成了点点鼠标就能完成的事。我把它部署在客户内网后DBA 从每天花 2 小时处理工单变成 15 分钟扫一眼健康报告。技术没有银弹但省下的时间真真切切换来了更多睡眠。希望帮到你。本文还有配套的精品资源点击获取