数据库性能调优（一）
性能指标：
- 相应指标
- 吞吐量
- 可拓展性
数据库性能优化误区：
-
加硬件能缓解性能问题
-
只要数据库性能好就没问题
=> 应用层能处理的不要转移到数据库处理
=> 频繁数据库交互会对网络和数据库连接池带来严重的负担
-
任何数据库性能问题都可以通过索引来解决
=> 首先性能问题应该先排查原因，看日志
=> 其次通过修改 sql、表结构查看成效
=> 最后再考虑加索引
-
编码过于激进、极端
× 一切实现都在应用端、一切实现通过 procedure
影响数据库性能的因素：
-
数据库结构的设计
最明显！不好的设计影响整个系统以及后期调优！
好的设计出自好的设计，优化贯穿整个软件的生命周期！
-
事务和隔离级别
=> 确保每一个事务都是最小化
=> 同时确保事务的异常能够捕捉
-
数据文件配置
TempDB (全局资源) 独立驱动器
用户数据库和日志文件隔离存放
-
T-SQL语句的编写
了解业务
=> 确定业务需要用到的字段是否用到索引，有没有必要在字段上添加索引
=> 不要对有索引的字段使用任何计算包括函数，否则会导致查询无法使用索引，进而进行全表搜索
=> 只查询需要查询的字段
=> 使用简单SQL语句进行查询 (简单地关联24个表，或单表查询；没有复杂的过滤条件，只有23个条件判断，并且有一个过滤条件（使用等号）；可以使用索引查找操作 )
=> 越是复杂的语句，在业务量较大的系统中，语句执行计划产生的变异（大量的IO、CPU以及内存的压力）的几率会很高
=> 以小表驱动大表
-
硬件资源
优化方向：
-
了解业务，基于业务优化
-
优先考虑第三范式设计
适当冗余提高查询效率（冗余可以避免过多表关联，但也会带来维护成本）
-
表关联尽可能少
-
坚持最小原则
字段设计尽可能小、
-
在适当的地方使用约束，极致性能大多数不是我们需要的
出于安全考虑适当加一些约束
SQL Server 执行计划分析
T-SQL语句 -> 语法分析 -> 绑定 -> 优化 -> 执行 -> 返回结果
编写尽可能简单的、健壮的SQL语句生成良好的执行计划，极佳效果
数据运算符：
扫描运算符：表查找、聚集索引扫描、非聚集索引扫描
查找运算符：
标签查找（键查找，RID查找）有问题，索引没有覆盖
关联运算符：
对于外部输入的每一行，都会扫描内部输入，然后输出匹配行。
小数量的输入表为外部表，以较大数据量的集合为内部表
对于外部表进行扫描，对于内部表进行索引查找
合并连接 (Merge join)
会从两个数据集（都要排序）中，各取一个值进行比较，如果相等就把两行连接起来返回，如果不等，就把小的值去掉，按顺序取下一个值，对大表操作要高效一些。
哈希连接 (Hash Match)
会使用来自顶部输入的每一行生成哈希表，使用来自底部输入的每一行探测整个哈希表，然后输入所有匹配行
不需要预先排序，也不要求有索引，适合并行执行。最消耗资源的关联运算符
