sql数据库服务器怎么优化，配置要求有哪些？

sql数据库服务器再怎么弄，核心思路就一句话：先定位瓶颈，再针对索引、查询、内存、磁盘四项逐个击破，别一上来就重启或者加硬件。

很多人一遇到sql数据库服务器卡顿，第一反应是”重启一下”，或者”把内存加大”，说实话，大部分情况下这种操作解决不了根子上的问题，数据库服务器跟普通电脑不一样，它的性能问题往往藏在查询语句和数据结构里，下面我把这些年折腾sql数据库服务器的经验，按优先级一步步拆开讲,照着做基本能扛住大多数场景。

加载中

尚硅谷MySQL数据库高级，mysql优化，数据库优化

尚

尚硅谷

97.1万--

原视频地址

先给sql数据库服务器做个体检

在动手改任何配置之前，先搞清楚这台机器到底慢在哪儿，盲目调参等于瞎猜,浪费时间还容易把原本稳定的环境搞乱。

看等待类型

登录服务器后，先执行下面这条SQL,看看当前数据库正在等什么：

SELECT wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
ORDER BY wait_time_ms DESC;

输出结果里，如果排在前面的是PAGEIOLATCH，说明磁盘IO扛不住了；如果是LCKM，说明锁等待严重，多半有长事务或者死锁；如果是RESOURCE_SEMAPHORE，则说明内存压力大,查询在排队等内存授予。

看近期慢查询

打开SQL Server Management Studio，右键实例选择”活动监视器”,或者直接跑这条语句找累积耗时最长的查询：

SELECT TOP 10 total_worker_time/execution_count AS avg_cpu,
       total_elapsed_time/execution_count AS avg_elapsed,
       execution_count,
       query_text.text
FROM sys.dm_exec_query_stats
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS query_text
ORDER BY avg_elapsed DESC;

找到那个执行频率高且平均耗时长的查询，把它当成重点优化对象，手术刀要对准这块,而不是漫无目的地看所有查询。

看资源瓶颈

用性能监视器盯三个计数器：Processor % Processor Time、Memory Available MBytes、Physical Disk Avg. Disk Queue Length，如果磁盘队列长度长期大于2，基本可以断定磁盘是短板，业内专家指出，八成以上的sql数据库服务器性能问题，根源在磁盘和索引,而不是CPU。

sql数据库服务器连接不上怎么办

连接不上是高频故障，很多人遇到”无法连接到服务器”就重装,其实绝大多数情况是几个小地方没检查到。

网络和端口排查

先用命令测试基础连通性：

ping 数据库IP
telnet 数据库IP 1433

Telnet通说明端口能访问，通不了就检查防火墙和云安全组规则，如果是云服务器，记得去控制台把入方向1433端口放行，这一步经常被忽略,尤其是刚迁移到云上时。

服务状态检查

打开Windows服务管理器，找到SQL Server (MSSQLSERVER)，看看是不是”正在运行”，如果服务停了，右键启动，注意如果是命名实例，服务名会带实例名，比如SQL Server (SQLEXPRESS)。

如果服务能启动但连不上，查看Windows事件查看器里的SQL Server错误日志，路径一般在安装目录下的LOG文件夹，文件名类似ERRORLOG，里面有详细报错信息，Login failed for user ‘sa'”就是认证问题。

连接数配置

另一个常见原因是连接数被占满,执行：

SELECT DB_NAME(dbid) AS DBName, COUNT(1) AS ConnectionCount
FROM sys.sysprocesses
GROUP BY dbid;

如果连接数逼近上限，就要排查是否有应用没释放连接，同时检查最大连接数设置，在实例属性-连接里，看”最大并发连接数”是不是被调成了很小的值，默认是0（无限），但有些安全基线和优化脚本会改成几百,结果业务一上来就崩。

sql数据库服务器配置要求有哪些

很多人在采购前纠结配置，其实sql数据库服务器配置要求没有想象中那么玄乎，跑起来容易,跑得稳才考验硬件和参数的搭配。

内存和CPU怎么配

行业共识认为，sql数据库服务器配置要求的底线是8GB内存起步，16GB是常规操作，超过100GB的业务库建议32GB以上，内存和CPU的比例没有绝对公式，但有个参照：每个CPU核心配8-16GB内存,再根据并发量调整。

需要特别说明的是，SQL Server默认会吃掉几乎所有可用内存作为缓存，如果你机器上还跑着其他应用，记得在实例属性里设置最大服务器内存，别让它把系统内存耗尽,设置方法：

打开SSMS，右键实例选属性，内存页签，把”最大服务器内存(MB)”改成物理内存的80%左右，例如物理机32G,就填25600MB。

磁盘选型

磁盘是sql数据库服务器最容易踩坑的地方，机械硬盘跑OLTP业务，碰到稍大一点的查询就会让整个库卡死,下面是三种常见场景的选型参考：

tempdb数据库在安装时一定要放到独立磁盘或SSD上，tempdb存的是排序、哈希和临时表，这些操作全是随机IO,放在C盘和系统抢地盘纯属给自己找麻烦。

基础配置自检清单

按照下面的顺序过一遍，能避免80%的”未配置优化”问题：

• 数据库自动增长设置：打开数据文件属性，确认”自动增长”不是按百分比，改成按MB，比如每次增长512MB，避免频繁扩容引起性能抖动
• 恢复模式：生产库用”完整”模式，测试库可以改成”简单”，减少日志备份压力
• 最大服务器内存：按上文设置，别让SQL Server吃光物理内存
• NUMA节点：多路服务器检查是否启用了NUMA，通常默认自动配置即可，不用手动改

查询慢的优化套路

配置再好的sql数据库服务器，如果写的SQL语句是烂的，照样卡成PPT，优化查询是性价比最高的一步,不用加钱就能让慢查询提速数倍。

索引失效的常见场景

索引不是建了就能用,下面这些写法会让索引变成摆设：

• 在 where 条件里对索引列做函数运算，WHERE DATEDIFF(day, create_time, GETDATE()) = 1
• 使用前导通配符，WHERE name LIKE '%李'
• 隐式类型转换，varchar 列跟数字比较

这些情况改起来都不难，函数运算改成范围条件，前导通配符换成全文检索或者改成后缀通配符,隐式转换把参数类型和列类型对齐。

重写查询的三个诀窍

第一，把子查询改成表连接，当年SQL Server优化器再聪明，遇到某些复杂的 IN 子查询也会犯迷糊，改成 INNER JOIN 之后执行计划往往更优。

第二，避免 SELECT ，只取需要的列,减少网络传输和内存开销。

第三，分批处理大事务，比如删除百万级数据，一次性 DELETE 会锁大表、撑爆日志，改成循环分批删除，每批1000行，中间加个 WAITFOR DELAY '00:00:01',对业务影响能降到最低。

补上缺失索引

执行带缺失索引提示的语句：

SELECT  FROM sys.dm_db_missing_index_details;

结果里会告诉你哪个表需要哪些列作为索引键，注意这个DMV记录的是SQL Server在查询失败后记录的缺失索引建议，所以只要业务跑得够久，这个结果就很靠谱，建议给重要的查询手动创建索引前，先对比现有索引,避免重复。

日常维护别偷懒

sql数据库服务器不是装完就能一直跑不管，定期维护能避免很多隐藏问题，而且操作很简单,几分钟就能做完。

索引碎片处理

索引碎片太多会导致扫描效率下降,用下面语句查看碎片率：

SELECT OBJECT_NAME(OBJECT_ID) AS TableName,
       index_id,
       index_type_desc,
       avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 30;

碎片率在30%以上，执行重组（ALTER INDEX ... REORGANIZE）就够了，不需要重建，只有当碎片率极高且页面密度很低时，才用 REBUILD，重建索引会锁表,建议在维护窗口做。

统计信息别过期

统计信息是优化器选执行计划的依据，如果过期，可能选了错误的索引，默认数据库开启了自动更新统计信息,但建议每周手动更新一次大表的统计信息：

UPDATE STATISTICS 你的表名;

如果表的数据量每天变化很大，可以考虑将自动更新阈值调低，或者用 sp_updatestats 更新整个库。

sql数据库服务器常见问题解答

为什么sql数据库服务器内存占用一直很高，但业务不慢？

这通常是正常的，SQL Server会利用空闲内存做数据缓存，这是设计机制，只要最大内存设置合理，且没有其他应用程序缺内存，就不用管它，如果内存持续接近上限并且出现大量RESOURCE_SEMAPHORE等待，就要检查查询内存授予过大,可能跟并行查询有关。

迁移sql数据库服务器时，直接用备份文件复制到新机器可行吗？

可行，但注意版本兼容性，高版本备份不能恢复到低版本，比如SQL Server 2019的备份文件无法直接恢复到2016，迁移后必须重建登录名和作业，或者使用 sp_configure 同步服务器级配置，最简单的方式是用SSMS的导入导出向导，但对大库来说效率太低，建议使用备份+还原,然后单独处理账号映射问题。

sql数据库服务器价格一般多少，云服务器和自建哪个划算？

sql数据库服务器价格一般多少取决于版本、硬件和部署方式，SQL Server标准版的许可证费用按核心数计算，入门配置加上2核CPU和16G内存的许可证大概在几万元，企业版会贵出数倍，云数据库按包年包月计费，入门规格每月几百到上千元，适合中小业务，自建则省了云服务费但多了运维成本，长期看人力投入更大，如果业务有合规要求，本地部署更稳妥；如果是新项目想快速上线,云托管SQL数据库更省心。

sql数据库服务器再怎么弄，核心都是围绕索引、SQL语句和资源配比这三块做文章，不要迷信某个”万能优化脚本”，也别一慢就加硬件，先看懂等待类型和缺失索引，再动配置，最后把日常维护做扎实，这套组合拳下来,你手上那台sql数据库服务器还能再战好几年。