今年年中接手了一个老系统的升级改造前端是 AngularJS后端数据层是 SQL Server。很多朋友一听 AngularJS 就觉得是过时技术我一开始也有点犹豫但真正把业务跑通之后我开始理解为什么那么多企业还在用这套组合。市面上的教程大多是“AngularJS 怎么做 CRUD”“SQL 怎么写查询”但很少人讲清楚一件事AngularJS 的双向绑定机制到底该怎么和 SQL 的结构化数据模型配合才能既快又稳还不留下安全隐患。这篇文章不打算讲那种高大上的理论我想用一个真实改造项目的经验把从数据库表设计、API 封装到前端控制器绑定的完整链路拆开来讲。适合正在维护 AngularJS 老项目的人也适合那些需要在传统技术栈上做新功能开发的团队参考。1. 项目定位与整体架构设计1.1 为什么还要做 AngularJS 与 SQL 的深度整合先说背景。这个系统是公司内部的资产管理系统跑了好几年页面还是后端渲染加 jQuery 那套老写法。业务部门现在提出了几个新需求资产台账要支持模糊搜索和组合筛选借用记录要实时刷新月度报表要按部门、类别多维度统计。如果继续用传统方式每个操作都要整页刷新用户体验差开发和维护的效率也低。一开始团队也讨论过要不要直接上 Vue 或 React但仔细评估之后还是放弃了。原因很简单业务逻辑都固化在现有 AngularJS 代码里控制器、服务、指令一整套体系是完整的如果推倒重来数据库结构可以保留但前端交互逻辑全部重写光回归测试就要耗掉大量时间。对于企业内部系统来说稳定压倒一切技术栈新旧不是第一考虑因素。所以这次改造的核心思路是在保留 AngularJS 前端骨架的前提下把数据访问层彻底打通。所谓“深度整合”不是简单地在 AngularJS 里写几个$http.get请求而是要让 SQL 的查询能力、事务能力、约束能力真正服务于前端的交互逻辑。比如前端一个“借出资产”的操作不是简单 UPDATE 一条记录而是涉及资产状态变更、借用记录插入、库存余量校验这三个步骤必须放在同一个 SQL 事务里完成。这种场景才是深度整合真正要解决的问题。还有一点很多人会忽略AngularJS 的双向绑定虽然在视图和数据模型之间建立了自动同步但这种同步是有成本的。如果后端返回上万行数据直接塞进 Scope页面的脏检查会卡到没法用。这就必须在 SQL 层就做好分页、筛选、聚合让 AngularJS 拿到的永远是“刚刚够用”的数据量。整套体系的设计逻辑应该让 SQL 做它擅长的事让 AngularJS 只负责交互呈现。1.2 技术选型与架构解析技术选型这块数据库我们继续用 SQL Server因为公司现有的数据量已经不小而且 SQL Server 的事务处理、索引优化、权限管理能力在企业场景下确实扎实。后端桥梁选择了 Node.js Express也有同事提议过 ASP.NET但考虑到团队现有成员的技能栈和后续维护成本Node.js 更顺手而且 AngularJS 本身就是 JavaScript 体系前后端语言大一统可以减少很多心智负担。整体架构可以分成三层前端层AngularJS 负责页面交互、表单校验、数据展示所有数据都通过 RESTful API 获取。API 层Express 路由接收请求校验参数调用数据库访问模块返回统一格式的 JSON。数据层SQL Server 存储数据承担查询、事务、约束、索引等工作。这个分层看起来简单但实际操作中有很多细节需要把控。比如 API 层的数据校验不能只靠前端做一轮校验后端的参数校验必须同样严格因为 SQL 语句的拼接点往往就出现在参数处理不当的地方。再比如 API 层返回的 JSON 格式要稳定统一前端控制器才能形成一套通用的数据解析逻辑而不是每个接口各写一套。技术选型对比我整理了一张表层级选型备选方案选择理由前端AngularJS 1.xVue 2/3、React老项目技术栈延续改动最小后端Node.js ExpressASP.NET Core、Java Spring Boot团队技能匹配与前端语言统一数据库SQL Server 2019MySQL、PostgreSQL企业环境稳定性好事务能力强数据库工具Navicat for SQL ServerSSMS、DBeaver跨平台可视化操作方便这里没有选择引入 ORM 框架比如 Sequelize 之类的原因是这套系统的查询逻辑比较复杂很多报表类的 SQL 要手动调优ORM 自动生成的语句既绕又难调性能。我们的做法是写一个轻量级的数据库访问模块使用mssql驱动SQL 语句手写但全部参数化既保留了 SQL 的灵活度又守住了安全底线。这个决定在后面排查慢查询的时候节省了大量时间。2. 核心细节拆解从 SQL 数据模型到 AngularJS 视图2.1 AngularJS 双向绑定如何对接 SQL 数据模型AngularJS 的核心特性就是双向绑定视图层的输入框、下拉框、表格会实时同步到 Scope 中的 JavaScript 对象。而 SQL 的数据模型是结构化的行和列两者之间的对接本质上是一个映射问题。比如数据库里有一张资产表Assets包含AssetID、AssetName、CategoryID、Status、PurchaseDate等字段。后端 API 查询出来的是一个 JSON 数组其中每个对象对应一行记录。AngularJS 的控制器里只需要把数组赋值给 Scope 上的变量视图中用ng-repeat就能自动渲染表格。这里没什么高深的东西真正的难点在于数据量大之后AngularJS 的脏检查机制暴露出来的性能问题。脏检查机制的原理是在每次$digest循环中遍历所有绑定到 Scope 的变量比较新旧值有变化就更新视图。这个机制在小数据量下完全没问题但数据量到几百上千条时浏览器就开始卡顿。我在表格渲染这一块踩过很深的坑后来总结出的方案是SQL 层做分页每次只取当前页的数据比如每页 50 条前端只在翻页时重新发起请求替换数据。这样减少了 Scope 中数据的规模脏检查的效率压力就大大降低。双向绑定和 SQL 数据模型的对接还需要特别关注字段命名问题。SQL Server 的字段命名习惯通常是PascalCase或snake_case而 AngularJS 社区的 JavaScript 惯例是camelCase。如果后端直接返回数据库原名字段前端代码写起来会很不舒服。我的做法是在 SQL 查询里给字段起别名统一转成camelCase比如SELECT AssetID AS assetId, AssetName AS assetName, CategoryID AS categoryId, Status AS status, PurchaseDate AS purchaseDate FROM Assets WHERE Status status;这样后端返回的 JSON 字段名就是前端期望的样子AngularJS 控制器里可以直接asset.assetName取值不需要再做一层字段名转换。这个小细节一开始没注意后来项目里十几个接口全部返工浪费了不少时间。2.2 后端 API 层安全与效率的关键防线API 层是整个整合链路中最容易出问题的地方。前端 AngularJS 发一个请求后端要把这个请求翻译成 SQL 操作中间任何一环处理不当轻则数据错误重则直接给攻击者打开大门。先谈安全。SQL 注入是首先要防的。很多老教程里还在教字符串拼接 SQL比如SELECT * FROM Users WHERE UserName userName 这要是在生产环境里跑等于把数据库裸奔给任何人。AngularJS 前端可以随便构造请求参数攻击者只要在输入框里输入一段恶意 SQL比如 OR 11就能绕过登录校验。热词里那个“sql注入万能密码绕过”说的就是这种攻击手法。解决方案就是参数化查询。以 Node.js 里的mssql驱动为例所有用户输入都通过input()方法绑定参数数据库驱动会自动对参数内容做转义防止被当作 SQL 语句执行const sql require(mssql); async function getUserByUsername(username) { const pool await sql.connect(dbConfig); const result await pool.request() .input(username, sql.NVarChar, username) .query(SELECT UserID, UserName, Role FROM Users WHERE UserName username); return result.recordset; }这里username是参数占位符input()方法把它绑定为sql.NVarChar类型。无论传入什么样的字符串都只会被当作一个普通字符串值来处理永远不可能变成 SQL 指令的一部分。另外API 层的权限控制也不能马虎。AngularJS 前端的按钮可以通过路由和指令控制显示但那只是用户体验层面的隐藏真正可靠的权限控制必须放在后端。每个 API 接口在处理请求之前要校验当前登录用户的角色和权限没有权限直接返回 403。我在项目里写了一个简单的权限中间件对所有涉及写操作的接口做了统一校验避免出现前端隐藏了按钮、但接口仍可直接调用被越权操作的情况。效率方面API 层要做的一件重要事情是参数预校验。比如分页参数pageSize如果传一个 100000SQL 层又不做限制一条查询就会把整个表的数据全捞出来内存直接爆掉。所以我在 API 层对分页参数做了上限限制const pageSize Math.min(parseInt(req.query.pageSize) || 20, 100); const pageIndex Math.max(parseInt(req.query.pageIndex) || 1, 1); const offset (pageIndex - 1) * pageSize;2.3 数据格式约定与前后端契约前后端联调最讨厌的事情就是数据格式不统一。一会儿返回数组一会儿返回对象一会儿错误信息在message里一会儿又在error里。AngularJS 控制器里写一堆分支判断维护起来极其痛苦。我在这次项目里做了一个统一的响应格式约定所有接口都返回相同结构的 JSON{ code: 0, message: success, data: { list: [], total: 100, pageIndex: 1, pageSize: 20 } }code为 0 表示成功非 0 表示业务错误码比如 1001 表示参数错误1002 表示无权限1003 表示数据不存在。message是人可读的描述信息。data是真正的业务数据。AngularJS 的服务层统一解析这个格式控制器只需要关注业务数据不需要关心错误处理逻辑的差异。这个契约还要解决一个非常实际的问题日期格式。SQL Server 的DATETIME字段通过mssql驱动返回后会变成 JavaScript 的Date对象序列化为 JSON 的时候默认会变成 ISO 字符串带时区偏移。而 AngularJS 的日期控件、表格显示有时需要YYYY-MM-DD有时需要YYYY-MM-DD HH:mm:ss。我在 SQL 层统一使用FORMAT函数处理日期输出格式SELECT AssetID AS assetId, AssetName AS assetName, FORMAT(PurchaseDate, yyyy-MM-dd) AS purchaseDate FROM Assets;这样后端返回的日期已经是格式化好的字符串AngularJS 直接显示不需要再折腾日期格式化过滤器。代价是 SQL 层多做了一点格式化工作但换来的是前后端逻辑的极大简化。另外枚举字段的映射也要在 SQL 层解决。比如资产状态Status字段在数据库里是TINYINT0 代表入库1 代表借出2 代表维修。如果直接返回数字AngularJS 模板里就要写一堆ng-if判断代码难看还不利于维护。我在 SQL 查询里用CASE WHEN把枚举值直接转成可读字符串SELECT AssetID AS assetId, AssetName AS assetName, CASE Status WHEN 0 THEN 入库 WHEN 1 THEN 借出 WHEN 2 THEN 维修 ELSE 未知 END AS statusText, Status AS statusCode FROM Assets;这样前端既拿到了用于显示的状态文字也保留了用于逻辑判断的状态数值。3. 实操过程一步一步搭建整合环境3.1 环境准备与数据库初始化先交代一下这套体系运行的环境。数据库用的 SQL Server 2019 标准版操作系统是 Windows Server。安装 SQL Server 的时候有几个坑至少在办公环境里遇到过好几次安装到一半提示“SQL 安装失败”十有八九是系统缺少 .NET Framework 组件或者杀毒软件拦截了安装进程。解决办法是先安装系统更新把 .NET Framework 4.8 装好安装 SQL Server 的时候暂时退出杀毒软件。如果安装日志里提示某个 Windows 服务启动失败先手动把服务对应的依赖服务启动起来再重试。数据库开发阶段我推荐用 Navicat for SQL Server 来管理和调试。Navicat 的可视化操作界面比 SSMS 轻量跨平台也好用。注意工具本身的授权要走正规渠道团队版价格也不贵别去网上搜那些激活码不安全不说出问题还没人给你兜底。用 Navicat 连 SQL Server 的时候连接方式选 SQL Server Authentication填好服务器地址、端口默认 1433、用户名密码。如果连接不上先检查 SQL Server 的 TCP/IP 协议是否启用这一步在 SQL Server 配置管理器里操作。接下来是建表。这里列举一张简化版的资产表和借用记录表作为后面示例的基础CREATE TABLE Assets ( AssetID INT IDENTITY(1,1) PRIMARY KEY, AssetCode NVARCHAR(50) NOT NULL UNIQUE, AssetName NVARCHAR(100) NOT NULL, CategoryID INT NOT NULL, Status TINYINT NOT NULL DEFAULT 0, PurchaseDate DATETIME NULL, CONSTRAINT FK_Assets_Category FOREIGN KEY (CategoryID) REFERENCES Categories(CategoryID) ); CREATE TABLE BorrowRecords ( RecordID INT IDENTITY(1,1) PRIMARY KEY, AssetID INT NOT NULL, BorrowerName NVARCHAR(50) NOT NULL, BorrowDate DATETIME NOT NULL DEFAULT GETDATE(), ReturnDate DATETIME NULL, Status TINYINT NOT NULL DEFAULT 0, CONSTRAINT FK_BorrowRecords_Asset FOREIGN KEY (AssetID) REFERENCES Assets(AssetID) );这两张表的结构很简单但已经覆盖了这次整合要用到的大部分操作场景单表查询、多表关联、状态更新、事务操作。3.2 后端 API 代码实现后端的核心模块是数据库访问。我用mssql驱动维护了一个连接池避免每个请求都新建数据库连接带来的开销const sql require(mssql); const dbConfig { user: asset_app, password: YourStrongPassword, server: localhost, database: AssetDB, options: { encrypt: false, trustServerCertificate: true }, pool: { max: 10, min: 0, idleTimeoutMillis: 30000 } }; async function query(sqlText, params) { const pool await sql.connect(dbConfig); const request pool.request(); if (params) { for (const key of Object.keys(params)) { request.input(key, params[key].type, params[key].value); } } const result await request.query(sqlText); return result.recordset; }这里有一个细节要说明连接池参数max设置为 10是因为这个内部系统的并发量并不高10 个连接足够满足需求连接数太多反而会占用数据库服务器的资源。如果外部并发访问量大这个参数要相应调大但不能无脑调大要结合 SQL Server 的最大连接数限制来设置。资产借出这个操作是整个系统里逻辑最复杂的需要在同一个 SQL 事务里完成三步操作。我封装了一个借用资产的接口app.post(/api/assets/borrow, async (req, res) { const { assetId, borrowerName, borrowDate } req.body; if (!assetId || !borrowerName) { return res.status(400).json({ code: 1001, message: 参数不完整 }); } const pool await sql.connect(dbConfig); const transaction new sql.Transaction(pool); try { await transaction.begin(); const request new sql.Request(transaction); // 第一步检查资产状态 const assetResult await request .input(assetId, sql.Int, assetId) .query(SELECT Status FROM Assets WITH (UPDLOCK, ROWLOCK) WHERE AssetID assetId); if (assetResult.recordset.length 0) { throw new Error(资产不存在); } const assetStatus assetResult.recordset[0].Status; if (assetStatus ! 0) { throw new Error(资产当前不可借出); } // 第二步更新资产状态 await request .input(assetId, sql.Int, assetId) .input(status, sql.TinyInt, 1) .query(UPDATE Assets SET Status status WHERE AssetID assetId); // 第三步插入借用记录 await request .input(assetId, sql.Int, assetId) .input(borrowerName, sql.NVarChar, borrowerName) .input(borrowDate, sql.DateTime, borrowDate || new Date()) .query(INSERT INTO BorrowRecords (AssetID, BorrowerName, BorrowDate, Status) VALUES (assetId, borrowerName, borrowDate, 0)); await transaction.commit(); res.json({ code: 0, message: success, data: null }); } catch (err) { await transaction.rollback(); res.status(500).json({ code: 1003, message: err.message }); } });这里的重点是事务的commit和rollback。如果三个步骤任何一步失败整个事务回滚保证资产状态和借用记录始终保持一致。另外一个容易被忽略的细节是WITH (UPDLOCK, ROWLOCK)锁提示这是为了防止高并发场景下两个请求同时读到“可借出”的状态然后都去更新导致数据不一致。虽然这个内部系统并发量不大但写代码的时候把这些边界考虑进去是职业习惯问题。3.3 AngularJS 前端集成实现前端部分AngularJS 的项目结构我按模块化来组织。先定义整个应用的主模块var assetApp angular.module(assetApp, [ngRoute]); assetApp.config([$routeProvider, function($routeProvider) { $routeProvider .when(/assets, { templateUrl: views/asset-list.html, controller: AssetListController }) .when(/assets/borrow, { templateUrl: views/asset-borrow.html, controller: AssetBorrowController }) .otherwise({ redirectTo: /assets }); }]);访问后端接口的逻辑抽到一个独立的 Service 里这样控制器不用关心 HTTP 请求的细节也方便统一处理错误assetApp.factory(AssetService, [$http, function($http) { return { getAssetList: function(params) { return $http.get(/api/assets, { params: params }); }, borrowAsset: function(data) { return $http.post(/api/assets/borrow, data); } }; }]);列表页的控制器核心逻辑就是调用 Service 取数据然后通过双向绑定自动渲染到表格assetApp.controller(AssetListController, [$scope, AssetService, function($scope, AssetService) { $scope.assets []; $scope.total 0; $scope.pageIndex 1; $scope.pageSize 50; $scope.loading false; $scope.loadAssets function() { $scope.loading true; AssetService.getAssetList({ pageIndex: $scope.pageIndex, pageSize: $scope.pageSize, keyword: $scope.keyword }).then(function(res) { if (res.data.code 0) { $scope.assets res.data.data.list; $scope.total res.data.data.total; } $scope.loading false; }, function() { $scope.error 加载失败请检查网络; $scope.loading false; }); }; $scope.search function() { $scope.pageIndex 1; $scope.loadAssets(); }; $scope.loadAssets(); }]);对应视图模板里的核心部分table classtable table-striped thead tr th资产编码/th th资产名称/th th状态/th th购入日期/th th操作/th /tr /thead tbody tr ng-repeatasset in assets td{{ asset.assetCode }}/td td{{ asset.assetName }}/td td{{ asset.statusText }}/td td{{ asset.purchaseDate }}/td tdbutton ng-clickborrow(asset)借出/button/td /tr /tbody /table这里ng-repeat就是双向绑定和数据驱动视图的直观体现。只要 Scope 中的assets数组变化了DOM 表格会自动重新渲染不需要手动操作 DOM。这个模式写起来很舒服但前面提到过性能问题所以我把分页逻辑设计成每次只加载 50 条在 SQL 层用OFFSET FETCH分页AngularJS 这边只维护当前页数据。3.4 联调与部署要点前后端联调的阶段最容易踩的坑是跨域。如果 AngularJS 页面跑在 8080 端口后端 Node.js API 跑在 3000 端口浏览器会拦截跨域请求。解决办法有两种一种是在后端启用 CORS 中间件另一种更简单——在开发环境用 Nginx 做反向代理把/api前缀的请求转发到后端服务。我用的是第二种方式因为生产环境本身就需要 Nginx 托管静态页面顺手就能解决跨域问题。Nginx 的关键配置片段server { listen 80; server_name asset.internal.example.com; location / { root /var/www/asset-front; index index.html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那一行是 AngularJS 路由刷新不报 404 的关键。AngularJS 使用的是 Hash 路由正常情况不会触发服务端路由查找但如果未来改造为$locationProvider.html5Mode(true)这个配置就必须加上否则刷新非首页路径会直接 404。这里提前配置好等于给将来留了一条后路。部署阶段还要注意接口超时问题。SQL Server 如果遇到慢查询响应时间可能很长而 AngularJS 的$http默认超时时间是 120 秒一般够用。但要注意的是如果数据库连接池满了新请求会排队等待超时会被拉长。我在实际部署中会监控数据库活跃连接数和慢查询日志一旦发现问题优先优化 SQL而不是单纯去调前端超时参数。4. 常见问题与排查技巧实录4.1 SQL Server 环境问题排查环境类问题占了这个项目排查工作量的三成左右虽然不影响架构设计但处理起来很折磨人。这里整理几个高频问题的排查思路。SQL Server 安装失败。常见的原因集中在系统组件缺失、安装顺序冲突和权限不足。尤其是装了一些大型工业软件之后再装 SQL Server 很容易冲突。我的排查方法是看安装日志路径一般在C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\Log下。日志里会明确写出失败的具体步骤和错误码。如果提示0x858C001B之类的结果码多半是安装过程被中断清空注册表残留后重装即可。如果没把握清理干净最好的办法是用微软官方工具卸载再装不要手动动注册表。SQL Server 密码过期。热词里提到的“sql server 2012 密码到期”是个很典型的问题。默认安装 SQL Server 的时候如果启用了密码策略数据库登录账号的密码会按 Windows 策略定期过期。企业环境里经常发生某天突然连不上库报“登录失败”或“密码已过期”。解决方案是避免用 SQL Server 账号直接连数据库改为 Windows 身份验证模式或者在创建 SQL Server 账号时执行以下语句关闭密码过期策略ALTER LOGIN asset_app WITH CHECK_POLICY OFF; ALTER LOGIN asset_app WITH CHECK_EXPIRATION OFF;Navicat 连接不上 SQL Server。优先排查三层网络连通性登录账号权限SQL Server 的 TCP/IP 协议状态。telnet 服务器IP 1433测一下端口通没通不通就查防火墙。接着在 SQL Server 配置管理器里确认TCP/IP协议已启用且 IP 地址的监听端口没有被占用。账号权限方面测试登录时先用sa账户排除账号自身权限问题确认能连上后再逐步回收权限。4.2 SQL 注入与安全加固SQL 注入的防护在这个项目里是红线。前面已经提到参数化查询是标准做法但有些场景容易被忽略。第一类易忽略场景是动态排序。比如前端表格允许用户点击表头排序排序字段是拼接进 SQL 的。如果直接把字段名拼进去攻击者可以通过构造字段名注入恶意 SQL。虽然排序字段通常只能出现在ORDER BY后面但依然有风险。我的做法是把排序字段做成白名单const sortableColumns { assetCode: AssetCode, assetName: AssetName, purchaseDate: PurchaseDate }; const sortField sortableColumns[req.query.sortField] || AssetCode; const sortOrder req.query.sortOrder desc ? DESC : ASC;第二类易忽略场景是模糊搜索。LIKE % keyword %这种写法如果关键字里包含%或_就会被 SQL 的通配符解析导致查询结果不准确甚至成为注入点。处理办法是先对关键字做转义const keyword req.query.keyword.replace(/[%_]/g, function(match) { return \\ match; });然后在 SQL 中使用LIKE % keyword % ESCAPE \。第三类是通用登录绕过。前面提到的“万能密码绕过”本质就是开发者用字符串拼接方式构造了登录 SQL攻击者输入 OR 11等字符串让 WHERE 条件恒为真。这类漏洞的修复很简单统一用参数化查询就能解决。但要注意不要以为用了存储过程就绝对安全如果存储过程内部也是用拼接字符串执行动态 SQL注入风险依然存在。排查时可以在 SQL Server 的sys.dm_exec_requests动态管理视图中实时查看正在执行的 SQL 语句看看是否有可疑的拼接痕迹。4.3 慢 SQL 与查询性能优化AngularJS 和 SQL 深度整合之后用户对页面响应速度的感知会直接反映到 SQL 查询性能上。如果某个页面加载要 3 秒以上用户体验会非常糟糕。这次项目里排查和优化慢 SQL 的经历值得单独拿出来讲。慢 SQL 的定位在 SQL Server 上可以先开启慢查询捕获。用sys.dm_exec_query_stats动态管理视图可以查到耗时靠前的 SQL 语句SELECT TOP 10 qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time, qs.execution_count, SUBSTRING(st.text, (qs.statement_start_offset/2) 1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) 1) AS query_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st ORDER BY avg_elapsed_time DESC;定位到慢 SQL 之后优先看执行计划。SQL Server Management Studio 或 Navicat 里都能查看图形化执行计划。重点关注两个标志表扫描Table Scan和索引扫描Index Scan。如果看到这两个操作说明查询没有走索引数据量一大性能必然下降。这次项目里让我印象最深刻的一个优化案例是资产列表的组合筛选查询。SQL 语句带多个筛选条件每次查询都全表扫描数据量到 10 万行以后响应时间直接飙到 4 秒。优化方案是建了组合索引CREATE NONCLUSTERED INDEX IX_Assets_Category_Status ON Assets (CategoryID, Status) INCLUDE (AssetName, PurchaseDate);这个索引让WHERE CategoryID categoryId AND Status status的查询从全表扫描变成了索引查找响应时间从 4 秒降到了 200 毫秒左右。索引设计的原则是区分度高的字段放前面用于过滤的字段放前面需要回表查询的字段放进INCLUDE里。另外要处理的一类慢查询是去重操作。热词里反复出现的“sql语句去重”“sql语句去重查询”在日常业务中确实很常见。两张方式-- 方式一DISTINCT 去重 SELECT DISTINCT CategoryID FROM Assets; -- 方式二窗口函数去重适用于需要保留完整行数据的场景 SELECT * FROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY AssetID ORDER BY PurchaseDate DESC) AS rn FROM Assets ) AS t WHERE t.rn 1;DISTINCT适合简单去重但如果你要基于去重逻辑保留某一行完整的数据ROW_NUMBER() OVER(PARTITION BY ...)窗口函数更可靠。窗口函数在 SQL Server 2019 里已经很好用了这一块值得花时间掌握。关于 SQL 优化还有一个经验教训千万不要盲目加索引。索引不是越多越好每个索引都会占用磁盘空间还会拖慢写入速度。我见过有些同事为了优化查询把所有涉及的组合都建了索引结果一张表十几个索引写入性能严重下降。正确的做法是先看慢查询日志针对最频繁、最耗时的查询精准设计索引宁缺毋滥。写在最后的一点实际体会这个项目改造下来我个人最大的体会是AngularJS 和 SQL 的整合技术难点其实不在框架本身而在数据链路的每个节点上。SQL 层要考虑查询性能、数据一致性、安全防护API 层要考虑参数校验、统一格式、事务处理AngularJS 层要考虑数据规模、绑定效率、交互体验任何一环有短板整个系统的体验都会被拖累。如果你也正在维护一个 AngularJS 老项目我的建议是先别急着推翻重写把数据库访问层、API 层、前端数据映射这些链路梳理清楚性能优化和安全加固做完老系统完全可以焕发新的生命力。最后再分享一个小技巧SQL Server 的FORMAT函数虽然方便但性能开销比较大如果在查询量大、数据量高的场景下日期格式化尽量在 API 层或前端做别过度依赖 SQL 函数。这个细节是我在压测阶段发现的一条查询里用了三个FORMAT查询时间直接翻倍。后来改成后端处理日期格式性能明显改善。技术选型没有银弹每个环节都要根据实际场景做权衡。
今年年中接手了一个老系统的升级改造前端是 AngularJS后端数据层是 SQL Server。很多朋友一听 AngularJS 就觉得是过时技术我一开始也有点犹豫但真正把业务跑通之后我开始理解为什么那么多企业还在用这套组合。市面上的教程大多是“AngularJS 怎么做 CRUD”“SQL 怎么写查询”但很少人讲清楚一件事AngularJS 的双向绑定机制到底该怎么和 SQL 的结构化数据模型配合才能既快又稳还不留下安全隐患。这篇文章不打算讲那种高大上的理论我想用一个真实改造项目的经验把从数据库表设计、API 封装到前端控制器绑定的完整链路拆开来讲。适合正在维护 AngularJS 老项目的人也适合那些需要在传统技术栈上做新功能开发的团队参考。1. 项目定位与整体架构设计1.1 为什么还要做 AngularJS 与 SQL 的深度整合先说背景。这个系统是公司内部的资产管理系统跑了好几年页面还是后端渲染加 jQuery 那套老写法。业务部门现在提出了几个新需求资产台账要支持模糊搜索和组合筛选借用记录要实时刷新月度报表要按部门、类别多维度统计。如果继续用传统方式每个操作都要整页刷新用户体验差开发和维护的效率也低。一开始团队也讨论过要不要直接上 Vue 或 React但仔细评估之后还是放弃了。原因很简单业务逻辑都固化在现有 AngularJS 代码里控制器、服务、指令一整套体系是完整的如果推倒重来数据库结构可以保留但前端交互逻辑全部重写光回归测试就要耗掉大量时间。对于企业内部系统来说稳定压倒一切技术栈新旧不是第一考虑因素。所以这次改造的核心思路是在保留 AngularJS 前端骨架的前提下把数据访问层彻底打通。所谓“深度整合”不是简单地在 AngularJS 里写几个$http.get请求而是要让 SQL 的查询能力、事务能力、约束能力真正服务于前端的交互逻辑。比如前端一个“借出资产”的操作不是简单 UPDATE 一条记录而是涉及资产状态变更、借用记录插入、库存余量校验这三个步骤必须放在同一个 SQL 事务里完成。这种场景才是深度整合真正要解决的问题。还有一点很多人会忽略AngularJS 的双向绑定虽然在视图和数据模型之间建立了自动同步但这种同步是有成本的。如果后端返回上万行数据直接塞进 Scope页面的脏检查会卡到没法用。这就必须在 SQL 层就做好分页、筛选、聚合让 AngularJS 拿到的永远是“刚刚够用”的数据量。整套体系的设计逻辑应该让 SQL 做它擅长的事让 AngularJS 只负责交互呈现。1.2 技术选型与架构解析技术选型这块数据库我们继续用 SQL Server因为公司现有的数据量已经不小而且 SQL Server 的事务处理、索引优化、权限管理能力在企业场景下确实扎实。后端桥梁选择了 Node.js Express也有同事提议过 ASP.NET但考虑到团队现有成员的技能栈和后续维护成本Node.js 更顺手而且 AngularJS 本身就是 JavaScript 体系前后端语言大一统可以减少很多心智负担。整体架构可以分成三层前端层AngularJS 负责页面交互、表单校验、数据展示所有数据都通过 RESTful API 获取。API 层Express 路由接收请求校验参数调用数据库访问模块返回统一格式的 JSON。数据层SQL Server 存储数据承担查询、事务、约束、索引等工作。这个分层看起来简单但实际操作中有很多细节需要把控。比如 API 层的数据校验不能只靠前端做一轮校验后端的参数校验必须同样严格因为 SQL 语句的拼接点往往就出现在参数处理不当的地方。再比如 API 层返回的 JSON 格式要稳定统一前端控制器才能形成一套通用的数据解析逻辑而不是每个接口各写一套。技术选型对比我整理了一张表层级选型备选方案选择理由前端AngularJS 1.xVue 2/3、React老项目技术栈延续改动最小后端Node.js ExpressASP.NET Core、Java Spring Boot团队技能匹配与前端语言统一数据库SQL Server 2019MySQL、PostgreSQL企业环境稳定性好事务能力强数据库工具Navicat for SQL ServerSSMS、DBeaver跨平台可视化操作方便这里没有选择引入 ORM 框架比如 Sequelize 之类的原因是这套系统的查询逻辑比较复杂很多报表类的 SQL 要手动调优ORM 自动生成的语句既绕又难调性能。我们的做法是写一个轻量级的数据库访问模块使用mssql驱动SQL 语句手写但全部参数化既保留了 SQL 的灵活度又守住了安全底线。这个决定在后面排查慢查询的时候节省了大量时间。2. 核心细节拆解从 SQL 数据模型到 AngularJS 视图2.1 AngularJS 双向绑定如何对接 SQL 数据模型AngularJS 的核心特性就是双向绑定视图层的输入框、下拉框、表格会实时同步到 Scope 中的 JavaScript 对象。而 SQL 的数据模型是结构化的行和列两者之间的对接本质上是一个映射问题。比如数据库里有一张资产表Assets包含AssetID、AssetName、CategoryID、Status、PurchaseDate等字段。后端 API 查询出来的是一个 JSON 数组其中每个对象对应一行记录。AngularJS 的控制器里只需要把数组赋值给 Scope 上的变量视图中用ng-repeat就能自动渲染表格。这里没什么高深的东西真正的难点在于数据量大之后AngularJS 的脏检查机制暴露出来的性能问题。脏检查机制的原理是在每次$digest循环中遍历所有绑定到 Scope 的变量比较新旧值有变化就更新视图。这个机制在小数据量下完全没问题但数据量到几百上千条时浏览器就开始卡顿。我在表格渲染这一块踩过很深的坑后来总结出的方案是SQL 层做分页每次只取当前页的数据比如每页 50 条前端只在翻页时重新发起请求替换数据。这样减少了 Scope 中数据的规模脏检查的效率压力就大大降低。双向绑定和 SQL 数据模型的对接还需要特别关注字段命名问题。SQL Server 的字段命名习惯通常是PascalCase或snake_case而 AngularJS 社区的 JavaScript 惯例是camelCase。如果后端直接返回数据库原名字段前端代码写起来会很不舒服。我的做法是在 SQL 查询里给字段起别名统一转成camelCase比如SELECT AssetID AS assetId, AssetName AS assetName, CategoryID AS categoryId, Status AS status, PurchaseDate AS purchaseDate FROM Assets WHERE Status status;这样后端返回的 JSON 字段名就是前端期望的样子AngularJS 控制器里可以直接asset.assetName取值不需要再做一层字段名转换。这个小细节一开始没注意后来项目里十几个接口全部返工浪费了不少时间。2.2 后端 API 层安全与效率的关键防线API 层是整个整合链路中最容易出问题的地方。前端 AngularJS 发一个请求后端要把这个请求翻译成 SQL 操作中间任何一环处理不当轻则数据错误重则直接给攻击者打开大门。先谈安全。SQL 注入是首先要防的。很多老教程里还在教字符串拼接 SQL比如SELECT * FROM Users WHERE UserName userName 这要是在生产环境里跑等于把数据库裸奔给任何人。AngularJS 前端可以随便构造请求参数攻击者只要在输入框里输入一段恶意 SQL比如 OR 11就能绕过登录校验。热词里那个“sql注入万能密码绕过”说的就是这种攻击手法。解决方案就是参数化查询。以 Node.js 里的mssql驱动为例所有用户输入都通过input()方法绑定参数数据库驱动会自动对参数内容做转义防止被当作 SQL 语句执行const sql require(mssql); async function getUserByUsername(username) { const pool await sql.connect(dbConfig); const result await pool.request() .input(username, sql.NVarChar, username) .query(SELECT UserID, UserName, Role FROM Users WHERE UserName username); return result.recordset; }这里username是参数占位符input()方法把它绑定为sql.NVarChar类型。无论传入什么样的字符串都只会被当作一个普通字符串值来处理永远不可能变成 SQL 指令的一部分。另外API 层的权限控制也不能马虎。AngularJS 前端的按钮可以通过路由和指令控制显示但那只是用户体验层面的隐藏真正可靠的权限控制必须放在后端。每个 API 接口在处理请求之前要校验当前登录用户的角色和权限没有权限直接返回 403。我在项目里写了一个简单的权限中间件对所有涉及写操作的接口做了统一校验避免出现前端隐藏了按钮、但接口仍可直接调用被越权操作的情况。效率方面API 层要做的一件重要事情是参数预校验。比如分页参数pageSize如果传一个 100000SQL 层又不做限制一条查询就会把整个表的数据全捞出来内存直接爆掉。所以我在 API 层对分页参数做了上限限制const pageSize Math.min(parseInt(req.query.pageSize) || 20, 100); const pageIndex Math.max(parseInt(req.query.pageIndex) || 1, 1); const offset (pageIndex - 1) * pageSize;2.3 数据格式约定与前后端契约前后端联调最讨厌的事情就是数据格式不统一。一会儿返回数组一会儿返回对象一会儿错误信息在message里一会儿又在error里。AngularJS 控制器里写一堆分支判断维护起来极其痛苦。我在这次项目里做了一个统一的响应格式约定所有接口都返回相同结构的 JSON{ code: 0, message: success, data: { list: [], total: 100, pageIndex: 1, pageSize: 20 } }code为 0 表示成功非 0 表示业务错误码比如 1001 表示参数错误1002 表示无权限1003 表示数据不存在。message是人可读的描述信息。data是真正的业务数据。AngularJS 的服务层统一解析这个格式控制器只需要关注业务数据不需要关心错误处理逻辑的差异。这个契约还要解决一个非常实际的问题日期格式。SQL Server 的DATETIME字段通过mssql驱动返回后会变成 JavaScript 的Date对象序列化为 JSON 的时候默认会变成 ISO 字符串带时区偏移。而 AngularJS 的日期控件、表格显示有时需要YYYY-MM-DD有时需要YYYY-MM-DD HH:mm:ss。我在 SQL 层统一使用FORMAT函数处理日期输出格式SELECT AssetID AS assetId, AssetName AS assetName, FORMAT(PurchaseDate, yyyy-MM-dd) AS purchaseDate FROM Assets;这样后端返回的日期已经是格式化好的字符串AngularJS 直接显示不需要再折腾日期格式化过滤器。代价是 SQL 层多做了一点格式化工作但换来的是前后端逻辑的极大简化。另外枚举字段的映射也要在 SQL 层解决。比如资产状态Status字段在数据库里是TINYINT0 代表入库1 代表借出2 代表维修。如果直接返回数字AngularJS 模板里就要写一堆ng-if判断代码难看还不利于维护。我在 SQL 查询里用CASE WHEN把枚举值直接转成可读字符串SELECT AssetID AS assetId, AssetName AS assetName, CASE Status WHEN 0 THEN 入库 WHEN 1 THEN 借出 WHEN 2 THEN 维修 ELSE 未知 END AS statusText, Status AS statusCode FROM Assets;这样前端既拿到了用于显示的状态文字也保留了用于逻辑判断的状态数值。3. 实操过程一步一步搭建整合环境3.1 环境准备与数据库初始化先交代一下这套体系运行的环境。数据库用的 SQL Server 2019 标准版操作系统是 Windows Server。安装 SQL Server 的时候有几个坑至少在办公环境里遇到过好几次安装到一半提示“SQL 安装失败”十有八九是系统缺少 .NET Framework 组件或者杀毒软件拦截了安装进程。解决办法是先安装系统更新把 .NET Framework 4.8 装好安装 SQL Server 的时候暂时退出杀毒软件。如果安装日志里提示某个 Windows 服务启动失败先手动把服务对应的依赖服务启动起来再重试。数据库开发阶段我推荐用 Navicat for SQL Server 来管理和调试。Navicat 的可视化操作界面比 SSMS 轻量跨平台也好用。注意工具本身的授权要走正规渠道团队版价格也不贵别去网上搜那些激活码不安全不说出问题还没人给你兜底。用 Navicat 连 SQL Server 的时候连接方式选 SQL Server Authentication填好服务器地址、端口默认 1433、用户名密码。如果连接不上先检查 SQL Server 的 TCP/IP 协议是否启用这一步在 SQL Server 配置管理器里操作。接下来是建表。这里列举一张简化版的资产表和借用记录表作为后面示例的基础CREATE TABLE Assets ( AssetID INT IDENTITY(1,1) PRIMARY KEY, AssetCode NVARCHAR(50) NOT NULL UNIQUE, AssetName NVARCHAR(100) NOT NULL, CategoryID INT NOT NULL, Status TINYINT NOT NULL DEFAULT 0, PurchaseDate DATETIME NULL, CONSTRAINT FK_Assets_Category FOREIGN KEY (CategoryID) REFERENCES Categories(CategoryID) ); CREATE TABLE BorrowRecords ( RecordID INT IDENTITY(1,1) PRIMARY KEY, AssetID INT NOT NULL, BorrowerName NVARCHAR(50) NOT NULL, BorrowDate DATETIME NOT NULL DEFAULT GETDATE(), ReturnDate DATETIME NULL, Status TINYINT NOT NULL DEFAULT 0, CONSTRAINT FK_BorrowRecords_Asset FOREIGN KEY (AssetID) REFERENCES Assets(AssetID) );这两张表的结构很简单但已经覆盖了这次整合要用到的大部分操作场景单表查询、多表关联、状态更新、事务操作。3.2 后端 API 代码实现后端的核心模块是数据库访问。我用mssql驱动维护了一个连接池避免每个请求都新建数据库连接带来的开销const sql require(mssql); const dbConfig { user: asset_app, password: YourStrongPassword, server: localhost, database: AssetDB, options: { encrypt: false, trustServerCertificate: true }, pool: { max: 10, min: 0, idleTimeoutMillis: 30000 } }; async function query(sqlText, params) { const pool await sql.connect(dbConfig); const request pool.request(); if (params) { for (const key of Object.keys(params)) { request.input(key, params[key].type, params[key].value); } } const result await request.query(sqlText); return result.recordset; }这里有一个细节要说明连接池参数max设置为 10是因为这个内部系统的并发量并不高10 个连接足够满足需求连接数太多反而会占用数据库服务器的资源。如果外部并发访问量大这个参数要相应调大但不能无脑调大要结合 SQL Server 的最大连接数限制来设置。资产借出这个操作是整个系统里逻辑最复杂的需要在同一个 SQL 事务里完成三步操作。我封装了一个借用资产的接口app.post(/api/assets/borrow, async (req, res) { const { assetId, borrowerName, borrowDate } req.body; if (!assetId || !borrowerName) { return res.status(400).json({ code: 1001, message: 参数不完整 }); } const pool await sql.connect(dbConfig); const transaction new sql.Transaction(pool); try { await transaction.begin(); const request new sql.Request(transaction); // 第一步检查资产状态 const assetResult await request .input(assetId, sql.Int, assetId) .query(SELECT Status FROM Assets WITH (UPDLOCK, ROWLOCK) WHERE AssetID assetId); if (assetResult.recordset.length 0) { throw new Error(资产不存在); } const assetStatus assetResult.recordset[0].Status; if (assetStatus ! 0) { throw new Error(资产当前不可借出); } // 第二步更新资产状态 await request .input(assetId, sql.Int, assetId) .input(status, sql.TinyInt, 1) .query(UPDATE Assets SET Status status WHERE AssetID assetId); // 第三步插入借用记录 await request .input(assetId, sql.Int, assetId) .input(borrowerName, sql.NVarChar, borrowerName) .input(borrowDate, sql.DateTime, borrowDate || new Date()) .query(INSERT INTO BorrowRecords (AssetID, BorrowerName, BorrowDate, Status) VALUES (assetId, borrowerName, borrowDate, 0)); await transaction.commit(); res.json({ code: 0, message: success, data: null }); } catch (err) { await transaction.rollback(); res.status(500).json({ code: 1003, message: err.message }); } });这里的重点是事务的commit和rollback。如果三个步骤任何一步失败整个事务回滚保证资产状态和借用记录始终保持一致。另外一个容易被忽略的细节是WITH (UPDLOCK, ROWLOCK)锁提示这是为了防止高并发场景下两个请求同时读到“可借出”的状态然后都去更新导致数据不一致。虽然这个内部系统并发量不大但写代码的时候把这些边界考虑进去是职业习惯问题。3.3 AngularJS 前端集成实现前端部分AngularJS 的项目结构我按模块化来组织。先定义整个应用的主模块var assetApp angular.module(assetApp, [ngRoute]); assetApp.config([$routeProvider, function($routeProvider) { $routeProvider .when(/assets, { templateUrl: views/asset-list.html, controller: AssetListController }) .when(/assets/borrow, { templateUrl: views/asset-borrow.html, controller: AssetBorrowController }) .otherwise({ redirectTo: /assets }); }]);访问后端接口的逻辑抽到一个独立的 Service 里这样控制器不用关心 HTTP 请求的细节也方便统一处理错误assetApp.factory(AssetService, [$http, function($http) { return { getAssetList: function(params) { return $http.get(/api/assets, { params: params }); }, borrowAsset: function(data) { return $http.post(/api/assets/borrow, data); } }; }]);列表页的控制器核心逻辑就是调用 Service 取数据然后通过双向绑定自动渲染到表格assetApp.controller(AssetListController, [$scope, AssetService, function($scope, AssetService) { $scope.assets []; $scope.total 0; $scope.pageIndex 1; $scope.pageSize 50; $scope.loading false; $scope.loadAssets function() { $scope.loading true; AssetService.getAssetList({ pageIndex: $scope.pageIndex, pageSize: $scope.pageSize, keyword: $scope.keyword }).then(function(res) { if (res.data.code 0) { $scope.assets res.data.data.list; $scope.total res.data.data.total; } $scope.loading false; }, function() { $scope.error 加载失败请检查网络; $scope.loading false; }); }; $scope.search function() { $scope.pageIndex 1; $scope.loadAssets(); }; $scope.loadAssets(); }]);对应视图模板里的核心部分table classtable table-striped thead tr th资产编码/th th资产名称/th th状态/th th购入日期/th th操作/th /tr /thead tbody tr ng-repeatasset in assets td{{ asset.assetCode }}/td td{{ asset.assetName }}/td td{{ asset.statusText }}/td td{{ asset.purchaseDate }}/td tdbutton ng-clickborrow(asset)借出/button/td /tr /tbody /table这里ng-repeat就是双向绑定和数据驱动视图的直观体现。只要 Scope 中的assets数组变化了DOM 表格会自动重新渲染不需要手动操作 DOM。这个模式写起来很舒服但前面提到过性能问题所以我把分页逻辑设计成每次只加载 50 条在 SQL 层用OFFSET FETCH分页AngularJS 这边只维护当前页数据。3.4 联调与部署要点前后端联调的阶段最容易踩的坑是跨域。如果 AngularJS 页面跑在 8080 端口后端 Node.js API 跑在 3000 端口浏览器会拦截跨域请求。解决办法有两种一种是在后端启用 CORS 中间件另一种更简单——在开发环境用 Nginx 做反向代理把/api前缀的请求转发到后端服务。我用的是第二种方式因为生产环境本身就需要 Nginx 托管静态页面顺手就能解决跨域问题。Nginx 的关键配置片段server { listen 80; server_name asset.internal.example.com; location / { root /var/www/asset-front; index index.html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files那一行是 AngularJS 路由刷新不报 404 的关键。AngularJS 使用的是 Hash 路由正常情况不会触发服务端路由查找但如果未来改造为$locationProvider.html5Mode(true)这个配置就必须加上否则刷新非首页路径会直接 404。这里提前配置好等于给将来留了一条后路。部署阶段还要注意接口超时问题。SQL Server 如果遇到慢查询响应时间可能很长而 AngularJS 的$http默认超时时间是 120 秒一般够用。但要注意的是如果数据库连接池满了新请求会排队等待超时会被拉长。我在实际部署中会监控数据库活跃连接数和慢查询日志一旦发现问题优先优化 SQL而不是单纯去调前端超时参数。4. 常见问题与排查技巧实录4.1 SQL Server 环境问题排查环境类问题占了这个项目排查工作量的三成左右虽然不影响架构设计但处理起来很折磨人。这里整理几个高频问题的排查思路。SQL Server 安装失败。常见的原因集中在系统组件缺失、安装顺序冲突和权限不足。尤其是装了一些大型工业软件之后再装 SQL Server 很容易冲突。我的排查方法是看安装日志路径一般在C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\Log下。日志里会明确写出失败的具体步骤和错误码。如果提示0x858C001B之类的结果码多半是安装过程被中断清空注册表残留后重装即可。如果没把握清理干净最好的办法是用微软官方工具卸载再装不要手动动注册表。SQL Server 密码过期。热词里提到的“sql server 2012 密码到期”是个很典型的问题。默认安装 SQL Server 的时候如果启用了密码策略数据库登录账号的密码会按 Windows 策略定期过期。企业环境里经常发生某天突然连不上库报“登录失败”或“密码已过期”。解决方案是避免用 SQL Server 账号直接连数据库改为 Windows 身份验证模式或者在创建 SQL Server 账号时执行以下语句关闭密码过期策略ALTER LOGIN asset_app WITH CHECK_POLICY OFF; ALTER LOGIN asset_app WITH CHECK_EXPIRATION OFF;Navicat 连接不上 SQL Server。优先排查三层网络连通性登录账号权限SQL Server 的 TCP/IP 协议状态。telnet 服务器IP 1433测一下端口通没通不通就查防火墙。接着在 SQL Server 配置管理器里确认TCP/IP协议已启用且 IP 地址的监听端口没有被占用。账号权限方面测试登录时先用sa账户排除账号自身权限问题确认能连上后再逐步回收权限。4.2 SQL 注入与安全加固SQL 注入的防护在这个项目里是红线。前面已经提到参数化查询是标准做法但有些场景容易被忽略。第一类易忽略场景是动态排序。比如前端表格允许用户点击表头排序排序字段是拼接进 SQL 的。如果直接把字段名拼进去攻击者可以通过构造字段名注入恶意 SQL。虽然排序字段通常只能出现在ORDER BY后面但依然有风险。我的做法是把排序字段做成白名单const sortableColumns { assetCode: AssetCode, assetName: AssetName, purchaseDate: PurchaseDate }; const sortField sortableColumns[req.query.sortField] || AssetCode; const sortOrder req.query.sortOrder desc ? DESC : ASC;第二类易忽略场景是模糊搜索。LIKE % keyword %这种写法如果关键字里包含%或_就会被 SQL 的通配符解析导致查询结果不准确甚至成为注入点。处理办法是先对关键字做转义const keyword req.query.keyword.replace(/[%_]/g, function(match) { return \\ match; });然后在 SQL 中使用LIKE % keyword % ESCAPE \。第三类是通用登录绕过。前面提到的“万能密码绕过”本质就是开发者用字符串拼接方式构造了登录 SQL攻击者输入 OR 11等字符串让 WHERE 条件恒为真。这类漏洞的修复很简单统一用参数化查询就能解决。但要注意不要以为用了存储过程就绝对安全如果存储过程内部也是用拼接字符串执行动态 SQL注入风险依然存在。排查时可以在 SQL Server 的sys.dm_exec_requests动态管理视图中实时查看正在执行的 SQL 语句看看是否有可疑的拼接痕迹。4.3 慢 SQL 与查询性能优化AngularJS 和 SQL 深度整合之后用户对页面响应速度的感知会直接反映到 SQL 查询性能上。如果某个页面加载要 3 秒以上用户体验会非常糟糕。这次项目里排查和优化慢 SQL 的经历值得单独拿出来讲。慢 SQL 的定位在 SQL Server 上可以先开启慢查询捕获。用sys.dm_exec_query_stats动态管理视图可以查到耗时靠前的 SQL 语句SELECT TOP 10 qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time, qs.execution_count, SUBSTRING(st.text, (qs.statement_start_offset/2) 1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) 1) AS query_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st ORDER BY avg_elapsed_time DESC;定位到慢 SQL 之后优先看执行计划。SQL Server Management Studio 或 Navicat 里都能查看图形化执行计划。重点关注两个标志表扫描Table Scan和索引扫描Index Scan。如果看到这两个操作说明查询没有走索引数据量一大性能必然下降。这次项目里让我印象最深刻的一个优化案例是资产列表的组合筛选查询。SQL 语句带多个筛选条件每次查询都全表扫描数据量到 10 万行以后响应时间直接飙到 4 秒。优化方案是建了组合索引CREATE NONCLUSTERED INDEX IX_Assets_Category_Status ON Assets (CategoryID, Status) INCLUDE (AssetName, PurchaseDate);这个索引让WHERE CategoryID categoryId AND Status status的查询从全表扫描变成了索引查找响应时间从 4 秒降到了 200 毫秒左右。索引设计的原则是区分度高的字段放前面用于过滤的字段放前面需要回表查询的字段放进INCLUDE里。另外要处理的一类慢查询是去重操作。热词里反复出现的“sql语句去重”“sql语句去重查询”在日常业务中确实很常见。两张方式-- 方式一DISTINCT 去重 SELECT DISTINCT CategoryID FROM Assets; -- 方式二窗口函数去重适用于需要保留完整行数据的场景 SELECT * FROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY AssetID ORDER BY PurchaseDate DESC) AS rn FROM Assets ) AS t WHERE t.rn 1;DISTINCT适合简单去重但如果你要基于去重逻辑保留某一行完整的数据ROW_NUMBER() OVER(PARTITION BY ...)窗口函数更可靠。窗口函数在 SQL Server 2019 里已经很好用了这一块值得花时间掌握。关于 SQL 优化还有一个经验教训千万不要盲目加索引。索引不是越多越好每个索引都会占用磁盘空间还会拖慢写入速度。我见过有些同事为了优化查询把所有涉及的组合都建了索引结果一张表十几个索引写入性能严重下降。正确的做法是先看慢查询日志针对最频繁、最耗时的查询精准设计索引宁缺毋滥。写在最后的一点实际体会这个项目改造下来我个人最大的体会是AngularJS 和 SQL 的整合技术难点其实不在框架本身而在数据链路的每个节点上。SQL 层要考虑查询性能、数据一致性、安全防护API 层要考虑参数校验、统一格式、事务处理AngularJS 层要考虑数据规模、绑定效率、交互体验任何一环有短板整个系统的体验都会被拖累。如果你也正在维护一个 AngularJS 老项目我的建议是先别急着推翻重写把数据库访问层、API 层、前端数据映射这些链路梳理清楚性能优化和安全加固做完老系统完全可以焕发新的生命力。最后再分享一个小技巧SQL Server 的FORMAT函数虽然方便但性能开销比较大如果在查询量大、数据量高的场景下日期格式化尽量在 API 层或前端做别过度依赖 SQL 函数。这个细节是我在压测阶段发现的一条查询里用了三个FORMAT查询时间直接翻倍。后来改成后端处理日期格式性能明显改善。技术选型没有银弹每个环节都要根据实际场景做权衡。
