SQL Server 用久了，很多人都有这种感觉：数据库越跑越慢，查询越来越卡，磁盘空间莫名其妙少了。其实，这些问题背后往往隐藏着一些容易被忽略的优化技巧——不是那种“换个更大服务器”的粗暴做法，而是从日常管理细节入手，让数据库自己跑得更顺畅。今天，我把几年实战中攒下来的经验挑几个最管用的，跟你聊聊。
先说说索引。很多人觉得索引越多查得越快，恨不得每个字段都加索引。这其实是个坑。索引确实能让查询加速，但它也有代价：每次插入、更新、删除数据，索引都得跟着重建，写操作就会变慢。而且索引本身占空间，存多了，磁盘和内存都扛不住。真正有效的做法是先分析你的查询模式——哪些字段经常出现在 WHERE 条件里？哪些字段用来排序和分组？针对这些字段建索引，其他字段别乱加。我见过一个项目，表里只有几十万条数据，索引却建了二十多个，结果查询速度还不如没索引的时候。删掉冗余索引后，磁盘占用立马降了 30%，查询时间也从几秒缩到毫秒级。
索引优化完了，别急着收工。接下来得盯紧执行计划。SQL Server 里有个好东西叫“实际执行计划”，它能告诉你每条查询是怎么跑的——用了哪些索引，走了什么连接方式，是不是扫描了整个表。很多人只管写 SQL，写完就跑，从不看执行计划长什么样。结果呢？明明可以用索引查找，却搞成全表扫描；明明可以用哈希连接，偏要走嵌套循环。这种问题，看执行计划一眼就能发现。我习惯在慢查询出现后把执行计划抓出来，找那些“成本占比高”的操作符，比如表扫描、键查找、排序，然后对症下药。改一条 SQL，往往能省下 80% 的 IO 开销。
说完查询，再说说日志管理。SQL Server 的事务日志简直是个无底洞，稍不注意就能撑爆磁盘。尤其是那些用了“完整恢复模式”的数据库，日志文件只增不减，除非定期做事务日志备份。很多人图省事，把恢复模式改成“简单”，以为万事大吉。结果呢？一旦需要时间点恢复，数据全没了。正确做法是：对关键业务库保持完整恢复模式，但设定好日志备份计划——比如每半小时或一小时备份一次，让 SQL Server 自动截断日志。备份文件要定期清理，别让它们堆成山。另外，日志文件别和数据文件放在同一个磁盘上，否则 IO 竞争会让性能直接腰斩。
接下来是统计信息。这玩意儿听起来技术，其实特别简单：SQL Server 依靠统计信息判断数据分布，从而选择最优的执行计划。如果统计信息过时，它就可能走错路——比如明明有索引，却偏要扫描。统计信息默认会自动更新，但触发条件是表中数据变化超过一定比例。对于小表，这个比例可能永远达不到，统计信息就永远不会更新。我见过一个案例，一张表每天只插入几百条数据，但全表也就几千条，结果统计信息两年没更新，查询计划全乱套。解决方案很直接：对活跃表手动设置统计信息更新频率，比如每次数据变化超过 10% 就更新一次，或者用定期作业，每周跑一次“更新统计信息”脚本。
索引碎片也是大问题。数据库用久了，索引页会分裂、碎片化，导致读取效率下降。碎片率超过 30% 时，扫描索引的成本会比预期高好几倍。解决办法是定期重新组织或重建索引。但别一上来就重建，那会锁表、占资源，生产环境扛不住。更聪明的做法是：先检查碎片率，低于 30% 的就重新组织，高于 30% 的才重建。而且重建时可以用 “ONLINE” 选项，让操作在线进行，不影响业务。我一般设一个每周一次的作业，自动检查所有索引的碎片率，然后按规则处理。这样既减少了维护窗口，又保证了查询性能。
再说说内存配置。SQL Server 是个内存大户，默认会吃掉几乎所有可用内存。如果服务器上还跑了其他应用，比如 Web 服务、报表服务，内存争抢就会拖慢一切。很多人不知道，SQL Server 有个“最大服务器内存”选项，可以限制它使用的内存。我的经验是：把总物理内存的 80% 左右分配给 SQL Server，剩下的留给操作系统和其他程序。但别死板，得根据实际情况调。比如实例只有几百 MB 数据，给 2 GB 内存就绰绰有余，再多也是浪费。反过来，如果数据量几十 GB，内存给少了，缓存命中率下降，磁盘 IO 就会飙升。调完内存后，用性能监视器看看 “Page Life Expectancy” 指标，低于 300 秒就说明内存不够了。
别忘了定期检查死锁。死锁不是偶发故障，它反映的是并发设计的缺陷。很多人遇到死锁就重启服务，治标不治本。正确的做法是：开启死锁跟踪标志（如 1222 或 1204），然后分析死锁图。死锁图会告诉你是哪两个事务、哪些资源、在什么顺序上发生冲突。看明白后，再调整事务顺序——比如让所有事务都按相同顺序访问表；或者缩短事务持续时间——别在事务里跑慢查询或等待用户输入。我一个朋友的公司死锁频发，查出来是两个存储过程对同一张表的更新顺序相反，改了一行代码后死锁直接消失。
这些技巧说穿了并不复杂，但难在坚持。很多人优化一次就跑，过几个月又回到老样子。其实，数据库管理是个持续的过程——今天优化索引，明天调整统计信息，后天清理日志，每一步都像给数据库做保养。你不需要一次性把所有事都做完，但要养成习惯，每周花半小时看看性能指标，跑跑维护脚本。这样下来，SQL Server 不仅跑得稳，还能省下不少硬件成本。那些说“数据库慢就升级服务器”的人，多半是没花时间做这些基础工作。
