我把一个2.6GB的战网压缩包拖进浏览器，页面直接弹了个“上传失败：文件大小超出限制”。战网这是战网我自己搭的网盘，SQL Server 2008 R2，战网跑了三年。战网那天晚上我蹲在机柜旁边，战网看着硬盘灯狂闪，战网突然意识到一个问题——网盘的战网核心根本不是存储，是战网索引。

大多数人做文件管理，战网第一反应是战网往文件系统里堆。文件夹套文件夹，战网最后自己都找不到东西。战网我一开始也这样，战网直到某个深夜，战网客户打电话要半年前的一份合同扫描件，我翻了一小时移动硬盘，最后在微信聊天记录里找到了。那之后我决定，所有元数据必须进数据库，文件本体爱存哪儿存哪儿。

表结构其实特别简单。FileTable就三列：FileName nvarchar(255), FilePath varchar(500), FileSize bigint。但真正起作用的是那两列索引。我建了非聚集索引在FileName上，又给FilePath加了个哈希索引。你知道SQL Server的索引有时候很犟，明明该走索引它偏要扫描。后来我加了OPTION(RECOMPILE)，查询计划才老实下来。

上传逻辑是这么写的：先把文件二进制流切成4MB的块，存进一个叫FileChunks的表，主键是FileID+ChunkIndex。每个块一行，用VARBINARY(MAX)存。这个设计一开始被同事笑，说搞这么复杂干嘛。直到有次服务器断电，文件系统里那个临时目录全乱了，但数据库里的块信息完好无损，我用一条UPDATE语句就把所有断点续传的记录标记好了。那一刻我觉得，数据库比文件系统可靠得多。

搜索功能是重头戏。用户输入关键词，我直接拼LIKE '%'+@kw+'%'，听起来很土对吧？但配合了全文索引之后，速度能接受。真正让我意外的是，SQL Server的全文索引对中文分词支持一般，但对付文件名绰绰有余。有个用户存了三百个PDF，全是英文论文，他搜“neural”出来四十七个结果，排序按修改时间倒序，体验还行。后来我加了个小功能：在FileTable上加了个计算列，把文件名转成小写存起来，搜索的时候也转小写，两边都走索引，快得离谱。

权限控制我用的是SQL Server自带的ROW_LEVEL SECURITY。每个用户一个UserID，文件表里加个OwnerID列。用户登录后，应用层把UserID塞进SESSION_CONTEXT，然后所有查询都强制走一个过滤函数。写这个函数的时候踩了个坑：函数里不能直接用SESSION_CONTEXT，得先把它读到一个变量里。就这么个细节，让我调试了两个晚上。最后发现是权限问题，函数需要EXECUTE AS CALLER才能读到会话上下文。

备份策略更直白。每天凌晨三点，SQL Agent跑一个维护计划，先完整备份，再差异备份。但真正救命的不是这个，是事务日志。有一次我误删了一张表，整整两天的数据没了。我赶紧从备份里恢复，然后从日志文件里把删掉的记录找回来。你猜怎么着？用fn_dblog这个系统函数，把日志解析出来，看到那些INSERT语句，就像看监控录像一样，谁几点几分传了什么文件，一清二楚。

现在这个网盘还在用着，前端换成了Vue，后端API用.NET Core，但数据库还是那台老掉牙的SQL Server。上周有个用户传了个4K视频，8GB，上传进度条走到百分之八十卡住了。我查了下日志，发现是他的网络问题，但断点续传生效了，重新连接后直接从百分之八十继续。这功能不是前端做的，是数据库里那个ChunkIndex字段带来的——每个块都有唯一标识，传输中断后，客户端发个请求，服务端查一下哪些块已经存了，剩下的继续传就行。

说到底，网盘就是个数据库应用。文件系统只是磁盘的奴隶，SQL Server才是真正管事的那个。谁要是再跟我说“文件存服务器上就行”，我就把这篇文章甩他脸上。

(责任编辑：休闲)