SQLServer 性能参数配置与调优

概述

SQL Server 性能参数配置是数据库运维的核心任务之一，直接影响数据库的性能和稳定性。合理配置性能参数可以充分利用系统资源，提高查询执行效率，减少瓶颈，确保数据库系统在高负载下稳定运行。

本文将详细介绍 SQL Server 性能相关参数的配置和调优，包括内存、CPU、IO 和查询优化等方面，兼顾不同版本的差异，提供实际生产场景的配置建议和示例，帮助 DBA 进行有效的性能调优。

内存参数配置

max server memory (MB)

参数说明：控制 SQL Server 实例可以使用的最大内存量，主要影响缓冲池的大小。

默认值：

SQL Server 2019 及以上：2,147,483,647 MB（无限制）
SQL Server 2017 及以下：根据操作系统和 SQL Server 版本有所不同

版本差异：

SQL Server 2012+：引入了内存管理的改进，更好地控制内存使用
SQL Server 2019+：默认值设置更为合理，减少了内存过度使用的风险

生产场景配置建议：

系统类型	配置建议
专用 SQL Server	设置为物理内存的 80-90%
共享服务器	根据其他应用的内存需求，合理分配内存
虚拟机	考虑虚拟机的内存限制，建议设置为分配给虚拟机内存的 90%

计算公式：

max_server_memory = (物理内存 - 操作系统预留内存 - 其他应用内存)

操作系统预留内存建议：

16 GB 以下：2 GB
16-64 GB：4 GB
64-256 GB：8 GB
256 GB 以上：16 GB

配置命令：

sql

-- 启用高级配置选项
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- 设置最大服务器内存为 32 GB
EXEC sp_configure 'max server memory (MB)', 32768;
RECONFIGURE;
-- 禁用高级配置选项（可选）
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

监控命令：

sql

-- 查看当前内存配置和使用情况
SELECT 
    name,
    value AS configured_value,
    value_in_use AS actual_value
FROM sys.configurations
WHERE name IN ('max server memory (MB)', 'min server memory (MB)');

-- 查看内存使用详情
SELECT 
    physical_memory_in_use_kb / 1024 AS physical_memory_used_mb,
    locked_page_allocations_kb / 1024 AS locked_pages_mb,
    virtual_address_space_committed_kb / 1024 AS virtual_memory_used_mb,
    available_commit_limit_kb / 1024 AS available_commit_limit_mb
FROM sys.dm_os_process_memory;

min server memory (MB)

参数说明：指定 SQL Server 实例保证使用的最小内存量，防止 SQL Server 频繁释放和重新获取内存。

默认值：0 MB

版本差异：

所有版本都支持此参数

生产场景配置建议：

专用 SQL Server：建议设置为 max_server_memory 的 50-70%，防止内存频繁波动
共享服务器：根据实际情况，设置一个合理的最小值，避免内存被其他应用过度占用
避免设置过大：防止影响操作系统和其他应用的内存使用

配置命令：

sql

-- 设置最小服务器内存为 16 GB
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'min server memory (MB)', 16384;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

optimize for ad hoc workloads

参数说明：优化临时工作负载，减少计划缓存占用，对于有大量即席查询的系统特别有用。

默认值：

所有版本：0 (OFF)

版本差异：

SQL Server 2008+：支持此参数

生产场景配置建议：

启用场景：
- 系统有大量临时查询（每次执行的 SQL 语句都不同）
- 计划缓存使用率高，但缓存命中率低
- 内存压力较大，需要减少计划缓存占用
禁用场景：
- 系统主要运行重复执行的查询
- 计划缓存使用率低

工作原理：

开启后，首次执行的即席查询会在计划缓存中存储一个小型存根（约 300 字节），而非完整执行计划
当查询再次执行时，才会存储完整执行计划
减少了计划缓存的内存占用，提高了缓存利用率

配置命令：

sql

-- 启用即席查询优化
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'optimize for ad hoc workloads', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

监控命令：

sql

-- 查看计划缓存使用情况
SELECT 
    objtype,
    count(*) AS plan_count,
    SUM(size_in_bytes) / 1024 / 1024 AS size_mb
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY size_mb DESC;

CPU 参数配置

max degree of parallelism (MAXDOP)

参数说明：控制查询并行执行时使用的最大处理器数量，直接影响查询的并行执行行为。

默认值：

SQL Server 2016 及以上：根据逻辑处理器数量自动设置
- 逻辑处理器 ≤ 8：使用所有可用处理器
- 逻辑处理器 > 8：使用 8 个处理器或 NUMA 节点的处理器数量（取较小值）
SQL Server 2014 及以下：0 (使用所有可用处理器)

版本差异：

SQL Server 2016+：引入了自动 MAXDOP 设置，根据硬件自动优化
SQL Server 2012+：支持 NUMA 感知的 MAXDOP 设置

生产场景配置建议：

工作负载类型	配置建议
OLTP 系统
逻辑处理器 ≤ 8	MAXDOP = 0 或逻辑处理器数量
逻辑处理器 > 8	MAXDOP = 8 或物理套接字数量
NUMA 架构	MAXDOP 不应超过单个 NUMA 节点的逻辑处理器数量
OLAP 系统	可以设置较高的 MAXDOP 值（如 16 或更高）
混合工作负载	建议设置为 4-8，根据实际测试调整

配置命令：

sql

-- 设置 MAXDOP 为 8
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 8;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

查询级别调整：

sql

-- 对于特定的 OLAP 查询，使用更高的 MAXDOP
SELECT * FROM LargeTable WHERE ComplexCondition
OPTION (MAXDOP 16);

-- 对于特定的 OLTP 查询，强制使用串行执行
SELECT * FROM SmallTable WHERE SimpleCondition
OPTION (MAXDOP 1);

监控命令：

sql

-- 查看并行查询的数量
SELECT 
    COUNT(*) AS parallel_queries
FROM sys.dm_exec_requests
WHERE dop > 1;

-- 查看等待并行工作线程的查询
SELECT 
    session_id,
    wait_type,
    wait_time_ms
FROM sys.dm_exec_requests
WHERE wait_type = 'CXPACKET';

cost threshold for parallelism

参数说明：指定查询优化器考虑并行执行的查询成本阈值，只有查询成本超过此值时，才会考虑使用并行执行。

默认值：

所有版本：5

版本差异：

所有版本都支持此参数
SQL Server 2016+：建议根据实际工作负载调整，默认值可能过低

生产场景配置建议：

工作负载类型	配置建议
OLTP 系统	30-50
OLAP 系统	5-10（保持默认或适当降低）
混合工作负载	20-30

配置命令：

sql

-- 设置成本阈值为 40
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'cost threshold for parallelism', 40;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

监控命令：

sql

-- 查看查询成本分布
SELECT 
    CASE 
        WHEN total_elapsed_time < 1000 THEN '< 1s'
        WHEN total_elapsed_time < 10000 THEN '1s-10s'
        WHEN total_elapsed_time < 60000 THEN '10s-1m'
        ELSE '> 1m'
    END AS duration_range,
    COUNT(*) AS query_count
FROM sys.dm_exec_query_stats
GROUP BY 
    CASE 
        WHEN total_elapsed_time < 1000 THEN '< 1s'
        WHEN total_elapsed_time < 10000 THEN '1s-10s'
        WHEN total_elapsed_time < 60000 THEN '10s-1m'
        ELSE '> 1m'
    END
ORDER BY query_count DESC;

lightweight pooling

参数说明：启用纤程模式，减少上下文切换开销，适用于特定硬件环境。

默认值：

所有版本：0 (OFF)

版本差异：

所有版本都支持此参数
现代版本中，此参数的作用已经很小，甚至可能导致性能下降

生产场景配置建议：

不建议启用：现代多核系统通常不需要启用，可能会导致性能下降
例外情况：
- 单处理器系统
- 上下文切换非常频繁的系统
注意事项：
- 开启后可能影响某些功能（如 CLR、Service Broker 等）
- 需要重启 SQL Server 服务才能生效

配置命令：

sql

-- 启用 lightweight pooling（仅在必要时）
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'lightweight pooling', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
-- 需要重启 SQL Server 服务才能生效

IO 参数配置

backup compression default

参数说明：指定备份操作是否默认使用压缩，直接影响备份文件大小和备份/恢复时间。

默认值：

SQL Server 2008 R2：0 (OFF)
SQL Server 2016 及以上：1 (ON)

版本差异：

SQL Server 2008 R2：引入备份压缩功能
SQL Server 2016+：默认启用备份压缩

生产场景配置建议：

建议开启 (1)：
- 减少备份文件大小（通常压缩率为 50-70%）
- 减少备份/恢复时间
- 减少存储成本和网络带宽占用
考虑因素：
- 开启后会增加 CPU 使用率（通常增加 5-15%）
- 对于 CPU 压力较大的系统，需要评估影响

配置命令：

sql

-- 启用默认备份压缩
EXEC sp_configure 'backup compression default', 1;
RECONFIGURE;

-- 查看当前配置
EXEC sp_configure 'backup compression default';

备份命令示例：

sql

-- 使用压缩备份（覆盖实例级设置）
BACKUP DATABASE [YourDatabase] 
TO DISK = N'D:\Backup\YourDatabase_FULL_20230101.bak' 
WITH COMPRESSION, STATS = 10;

-- 不使用压缩备份（覆盖实例级设置）
BACKUP DATABASE [YourDatabase] 
TO DISK = N'D:\Backup\YourDatabase_FULL_20230101.bak' 
WITH NO_COMPRESSION, STATS = 10;

查询优化参数

query governor cost limit

参数说明：限制查询的最大执行成本，超过该值的查询将被终止，防止长时间运行的查询占用过多资源。

默认值：

所有版本：0 (无限制)

版本差异：

所有版本都支持此参数

生产场景配置建议：

建议设置合理的限制值：
- OLTP 系统：100-500
- OLAP 系统：500-2000
注意事项：
- 结合查询超时设置使用
- 定期审查被终止的查询，优化高成本查询
- 对于特定的复杂查询，可以在查询级别使用 OPTION (QUERY_GOVERNOR_COST_LIMIT) 提示覆盖实例级设置

配置命令：

sql

-- 设置查询成本限制为 200
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'query governor cost limit', 200;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

查询级别调整：

sql

-- 为特定查询设置更高的成本限制
SELECT * FROM LargeTable WHERE ComplexCondition
OPTION (QUERY_GOVERNOR_COST_LIMIT 1000);

statistics time 和 statistics io

参数说明：

statistics time：显示每条语句的 CPU 时间和执行时间统计信息
statistics io：显示每条语句的 IO 统计信息

默认值：

所有版本：0 (OFF)

版本差异：

所有版本都支持此参数

生产场景配置建议：

仅在性能调优时临时开启：
- 生产环境建议保持关闭，减少性能开销
- 调优完成后及时关闭
使用场景：
- 分析查询性能瓶颈
- 比较不同查询写法的性能差异
- 验证索引优化效果

配置命令：

sql

-- 临时开启统计信息
SET STATISTICS TIME ON;
SET STATISTICS IO ON;

-- 执行查询
SELECT * FROM YourTable WHERE YourCondition;

-- 关闭统计信息
SET STATISTICS TIME OFF;
SET STATISTICS IO OFF;

版本差异汇总

参数名称	SQL Server 2012	SQL Server 2016	SQL Server 2019	SQL Server 2022
max server memory	默认值较大	默认值较大	默认值优化	默认值优化
MAXDOP	默认 0	自动设置	自动设置	自动设置
backup compression default	默认 OFF	默认 ON	默认 ON	默认 ON
optimize for ad hoc workloads	支持	支持	支持	支持
cost threshold for parallelism	默认 5	默认 5	默认 5	默认 5
lightweight pooling	默认 OFF	默认 OFF	默认 OFF	默认 OFF
query governor cost limit	默认 0	默认 0	默认 0	默认 0

性能调优最佳实践

内存调优

监控内存使用：定期监控 SQL Server 和操作系统的内存使用情况
避免内存压力：确保 SQL Server 有足够的内存，避免频繁的页交换
配置合理的 max server memory：根据系统配置和工作负载调整
启用 lock pages in memory：对于大内存系统，启用锁定内存页功能，减少页交换
监控计划缓存：定期检查计划缓存的使用情况，优化即席查询

CPU 调优

设置合理的 MAXDOP：根据工作负载类型和硬件配置调整
调整成本阈值：根据系统性能和查询复杂度调整 cost threshold for parallelism
监控并行查询：关注 CXPACKET 等待，避免过多并行查询导致的资源争用
优化查询：减少 CPU 密集型查询，优化索引和查询计划
考虑硬件升级：对于持续高 CPU 使用率的系统，考虑升级 CPU 或增加 CPU 核心数

IO 调优

分离数据和日志文件：将数据文件和日志文件存储在不同的磁盘上
使用 SSD 存储：对于 IO 密集型工作负载，使用 SSD 提高 IO 性能
合理配置文件增长：使用固定大小增长，避免百分比增长导致的碎片
优化索引：减少不必要的索引，优化索引设计，减少 IO 操作
监控 IO 等待：关注 PAGEIOLATCH_* 等待，及时发现 IO 瓶颈

查询优化

使用 Query Store：启用 Query Store，监控和分析查询性能
优化索引：定期检查索引使用情况，创建缺失索引，删除未使用的索引
优化查询计划：识别并修复低效的查询计划
参数化查询：减少即席查询，使用参数化查询提高计划缓存命中率
监控慢查询：定期审查慢查询，优化或重写

配置管理

逐步调整参数：每次只调整一个参数，观察效果后再调整其他参数
测试环境验证：新的参数配置在生产环境应用前，必须在测试环境进行验证
监控效果：调整参数后，使用性能监视器、DMV 等工具监控系统性能变化
记录配置变更：详细记录参数调整的原因、时间和效果，便于回滚和分析
定期审查：至少每季度审查一次参数配置，根据业务变化进行调整

常用性能监控脚本

内存使用情况

sql

-- 查看内存配置和使用情况
SELECT 
    -- 配置值
    (SELECT value FROM sys.configurations WHERE name = 'max server memory (MB)') AS max_server_memory_mb,
    (SELECT value FROM sys.configurations WHERE name = 'min server memory (MB)') AS min_server_memory_mb,
    -- 实际使用
    (SELECT physical_memory_in_use_kb / 1024 FROM sys.dm_os_process_memory) AS physical_memory_used_mb,
    (SELECT locked_page_allocations_kb / 1024 FROM sys.dm_os_process_memory) AS locked_pages_mb,
    -- 操作系统内存
    (SELECT total_physical_memory_kb / 1024 FROM sys.dm_os_sys_memory) AS total_os_memory_mb,
    (SELECT available_physical_memory_kb / 1024 FROM sys.dm_os_sys_memory) AS available_os_memory_mb;

CPU 使用情况

sql

-- 查看 CPU 使用情况
SELECT 
    scheduler_id,
    cpu_id,
    status,
    current_tasks_count,
    runnable_tasks_count AS cpu_ready_tasks,
    current_workers_count
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
ORDER BY cpu_ready_tasks DESC;

-- 查看消耗 CPU 最多的查询
SELECT TOP 10
    total_worker_time / 1000000 AS total_cpu_time_s,
    execution_count,
    total_worker_time / execution_count / 1000 AS avg_cpu_time_ms,
    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 total_cpu_time_s DESC;

IO 使用情况

sql

-- 查看磁盘 IO 统计信息
SELECT 
    DB_NAME(database_id) AS database_name,
    file_id,
    io_stall_read_ms / NULLIF(num_of_reads, 0) AS avg_read_latency_ms,
    io_stall_write_ms / NULLIF(num_of_writes, 0) AS avg_write_latency_ms,
    num_of_reads,
    num_of_writes,
    total_bytes_read / 1024 / 1024 AS total_read_mb,
    total_bytes_written / 1024 / 1024 AS total_write_mb
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
ORDER BY (io_stall_read_ms + io_stall_write_ms) DESC;

-- 查看消耗 IO 最多的查询
SELECT TOP 10
    total_logical_reads,
    total_logical_writes,
    execution_count,
    total_logical_reads / execution_count AS avg_logical_reads,
    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 total_logical_reads DESC;

常见问题 (FAQ)

为什么设置了 max server memory，但 SQL Server 仍使用更多内存？

答：max server memory 参数只控制 SQL Server 缓冲池的内存使用，不包括以下内存：

SQL Server 扩展存储过程 DLL
非共享的 SQL Server 排序内存
SQL Server 线程栈
SQL Server 以外的内存分配（如操作系统、其他应用）
CLR 内存
全文搜索内存

监控方法：使用 sys.dm_os_process_memory DMV 查看 SQL Server 进程的总内存使用情况。

如何确定最佳的 MAXDOP 值？

答：确定最佳 MAXDOP 值的方法：

参考 Microsoft 官方建议：根据工作负载类型和硬件配置
测试不同值：在测试环境中测试不同 MAXDOP 值下的系统性能
监控并行查询：观察 CXPACKET 等待和并行查询的数量
考虑 NUMA 架构：MAXDOP 不应超过单个 NUMA 节点的处理器数量
从保守值开始：建议从 4-8 开始，根据实际测试调整

为什么我的查询没有使用并行执行？

答：查询不使用并行执行的可能原因：

查询成本低于 cost threshold for parallelism：查询优化器认为串行执行更高效
查询中使用了不支持并行的操作符：如游标、XML 数据类型方法等
MAXDOP 设置为 1：实例级或查询级设置了 MAXDOP = 1
系统资源不足：CPU 使用率高或内存不足
查询涉及的表没有合适的索引：导致查询计划不适合并行执行
查询是小表查询：数据量小，串行执行更高效

如何监控参数配置的效果？

答：监控参数配置效果的方法：

SQL Server Performance Monitor：监控 CPU、内存、IO 等性能计数器
DMV 查询：使用 sys.dm_os_performance_counters、sys.dm_exec_query_stats 等 DMV 监控性能
Query Store：监控查询性能变化，比较参数调整前后的查询性能
扩展事件：捕获详细的性能事件，深入分析系统行为
等待统计信息：监控等待类型和等待时间，识别性能瓶颈
业务指标：关注业务相关的性能指标，如响应时间、吞吐量等

是否应该在实例级别设置所有参数？

答：建议在实例级别设置保守的默认值，对于特定的查询或数据库，可以在查询级别或数据库级别进行调整：

实例级别：设置适合大多数工作负载的默认值
数据库级别：使用 ALTER DATABASE SCOPED CONFIGURATION 命令设置数据库级别的参数
查询级别：使用查询提示（如 OPTION (MAXDOP 16)）调整特定查询的执行行为

示例：

sql

-- 数据库级别设置 MAXDOP
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 4;

-- 查询级别设置 MAXDOP
SELECT * FROM YourTable WHERE YourCondition OPTION (MAXDOP 16);

如何优化计划缓存？

答：优化计划缓存的方法：

启用 optimize for ad hoc workloads：减少即席查询的计划缓存占用
参数化查询：使用参数化查询提高计划缓存命中率
监控计划缓存使用情况：定期检查 sys.dm_exec_cached_plans，识别低效的缓存使用
清理过期的执行计划：对于长时间不使用的执行计划，可以使用 DBCC FREEPROCCACHE 清理
优化索引：减少查询计划的数量，提高计划重用率
避免过度索引：过多的索引会导致计划缓存膨胀

如何处理高 CPU 使用率？

答：处理高 CPU 使用率的步骤：

识别消耗 CPU 最多的进程：使用任务管理器或性能监视器
识别消耗 CPU 最多的查询：使用 sys.dm_exec_query_stats DMV
分析查询计划：查看消耗 CPU 最多的查询的执行计划
优化查询：重写查询、优化索引或调整查询计划
调整 MAXDOP：对于并行查询导致的高 CPU 使用率，调整 MAXDOP 设置
考虑硬件升级：对于持续高 CPU 使用率的系统，考虑升级 CPU 或增加 CPU 核心数

总结

SQL Server 性能参数配置是一个复杂的过程，需要根据系统的硬件配置、工作负载类型和业务需求进行综合考虑。合理配置性能参数可以充分利用系统资源，提高数据库性能，确保系统稳定运行。

在实际生产环境中，DBA 应该：

建立性能基准，了解系统的正常性能表现
定期监控系统性能，及时发现性能瓶颈
逐步调整性能参数，测试并验证效果
记录配置变更，便于回滚和分析
持续优化，适应业务变化和系统演进

通过本文的介绍，DBA 可以了解 SQL Server 主要性能参数的配置和调优方法，掌握性能监控和优化的最佳实践，提高数据库系统的性能和稳定性。

SQLServer 性能参数配置与调优 ​

概述 ​

内存参数配置 ​

max server memory (MB) ​

min server memory (MB) ​

optimize for ad hoc workloads ​

CPU 参数配置 ​

max degree of parallelism (MAXDOP) ​

cost threshold for parallelism ​

lightweight pooling ​

IO 参数配置 ​

backup compression default ​

查询优化参数 ​

query governor cost limit ​

statistics time 和 statistics io ​

版本差异汇总 ​

性能调优最佳实践 ​

内存调优 ​

CPU 调优 ​

IO 调优 ​

查询优化 ​

配置管理 ​

常用性能监控脚本 ​

内存使用情况 ​

CPU 使用情况 ​

IO 使用情况 ​

常见问题 (FAQ) ​

为什么设置了 max server memory，但 SQL Server 仍使用更多内存？ ​

如何确定最佳的 MAXDOP 值？ ​

为什么我的查询没有使用并行执行？ ​

如何监控参数配置的效果？ ​

是否应该在实例级别设置所有参数？ ​

如何优化计划缓存？ ​

如何处理高 CPU 使用率？ ​

总结 ​

SQLServer 性能参数配置与调优

概述

内存参数配置

max server memory (MB)

min server memory (MB)

optimize for ad hoc workloads

CPU 参数配置

max degree of parallelism (MAXDOP)

cost threshold for parallelism

lightweight pooling

IO 参数配置

backup compression default

查询优化参数

query governor cost limit

statistics time 和 statistics io

版本差异汇总

性能调优最佳实践

内存调优

CPU 调优

IO 调优

查询优化

配置管理

常用性能监控脚本

内存使用情况

CPU 使用情况

IO 使用情况

常见问题 (FAQ)

为什么设置了 max server memory，但 SQL Server 仍使用更多内存？

如何确定最佳的 MAXDOP 值？

为什么我的查询没有使用并行执行？

如何监控参数配置的效果？

是否应该在实例级别设置所有参数？

如何优化计划缓存？

如何处理高 CPU 使用率？

总结