数据库性能调优（一）

性能指标：

1. 相应指标
2. 吞吐量
3. 可拓展性

数据库性能优化误区：

1. 加硬件能缓解性能问题

2. 只要数据库性能好就没问题

   => 应用层能处理的不要转移到数据库处理

   => 频繁数据库交互会对网络和数据库连接池带来严重的负担

3. 任何数据库性能问题都可以通过索引来解决

   => 首先性能问题应该先排查原因，看日志

   => 其次通过修改 sql、表结构查看成效

   => 最后再考虑加索引

4. 编码过于激进、极端

   × 一切实现都在应用端、一切实现通过 procedure

影响数据库性能的因素：

• 数据库结构的设计

  最明显！不好的设计影响整个系统以及后期调优！

  好的设计出自好的设计，优化贯穿整个软件的生命周期！

• 事务和隔离级别

  => 确保每一个事务都是最小化

  => 同时确保事务的异常能够捕捉

• 数据文件配置

  TempDB (全局资源) 独立驱动器

  用户数据库和日志文件隔离存放

• T-SQL语句的编写

  了解业务

  => 确定业务需要用到的字段是否用到索引，有没有必要在字段上添加索引

  => 不要对有索引的字段使用任何计算包括函数，否则会导致查询无法使用索引，进而进行全表搜索

  => 只查询需要查询的字段

  => 使用简单SQL语句进行查询 (简单地关联2_{4个表，或单表查询；没有复杂的过滤条件，只有2}3个条件判断，并且有一个过滤条件（使用等号）；可以使用索引查找操作 )

  => 越是复杂的语句，在业务量较大的系统中，语句执行计划产生的变异（大量的IO、CPU以及内存的压力）的几率会很高

  => 以小表驱动大表

• 硬件资源

优化方向：

1. 了解业务，基于业务优化

2. 优先考虑第三范式设计

   适当冗余提高查询效率（冗余可以避免过多表关联，但也会带来维护成本）

3. 表关联尽可能少

4. 坚持最小原则

   字段设计尽可能小、

5. 在适当的地方使用约束，极致性能大多数不是我们需要的

   出于安全考虑适当加一些约束

SQL Server 执行计划分析

​ T-SQL语句 -> 语法分析 -> 绑定 -> 优化 -> 执行 -> 返回结果

​ 编写尽可能简单的、健壮的SQL语句生成良好的执行计划，极佳效果

数据运算符：

​ 扫描运算符：表查找、聚集索引扫描、非聚集索引扫描

查找运算符：

​ 标签查找（键查找，RID查找）有问题，索引没有覆盖

关联运算符：

​ 对于外部输入的每一行，都会扫描内部输入，然后输出匹配行。

​ 小数量的输入表为外部表，以较大数据量的集合为内部表

​ 对于外部表进行扫描，对于内部表进行索引查找

合并连接 (Merge join)

​ 会从两个数据集（都要排序）中，各取一个值进行比较，如果相等就把两行连接起来返回，如果不等，就把小的值去掉，按顺序取下一个值，对大表操作要高效一些。

哈希连接 (Hash Match)

​ 会使用来自顶部输入的每一行生成哈希表，使用来自底部输入的每一行探测整个哈希表，然后输入所有匹配行

​ 不需要预先排序，也不要求有索引，适合并行执行。最消耗资源的关联运算符