本文主要讲怎样提高数据库性能。
数据库性能问题的三个常见来源以及如何解决这些问题的建议。
避免死锁
死锁Deadlock，意思是当两个进程竞争性的对同一资源的独占访问，但一次只能有一个进程使用资源，从而数据库性能会降低，变得缓慢。
死锁有两种类型：循环锁Cyclelocks和转换锁Conversionlocks。
循环锁
进程要把一个被另一个进程锁定的资源转换独占锁时，就会发生循环锁。
转换锁
当一个线程试图将一个锁从一种独占类型转换为另一种独占类型，但同时由于另一个线程已经在该资源上持有共享锁，会导致转换锁。
转换锁有三种形式：
Shared with Intent Exclusive (SIX)：当持有共享锁的事务在某些页或行上也有独占锁时发生。
Shared with intent update (SIU)：当持有共享锁的事务也有一些页或行被更新锁锁定时发生。
Update with Intent Exclusive (UIX)：当持有更新锁的事务在某些页或行上也有独占锁时发生。
修复死锁的最佳方法是终止其中一个进程并释放锁定的资源。 为了防止死锁发生，预防措施如下：
创建更好的索引
调整事务优先级
持有锁的时间尽可能短
在获得所需的所有信息之前不要提交事务
索引的碎片整理
随着时间的推移，多次插入和删除会导致索引碎片化。这种碎片可能是内部的（由具有太多可用空间的页面引起）或外部的（当页面的逻辑顺序错误时发生）。
无论哪种类型，引发的一个症状是数据库的查询非常缓慢。
可以使用sys.dm_db_index_physical_stats诊断索引碎片:检测特定索引、表或索引视图上的所有索引、数据库中的所有索引或所有数据库中的所有索引中的碎片。
除非索引永远不会更改，否则无法防止某种程度的索引碎片。但是通过一些注意事项可以最大限度地减少碎片对数据库性能的影响：
要：注意可能导致页面拆分的功能
要：实施适当的索引填充因子
不要：更新记录以使其更长
不要：插入具有随机键值的记录
在修复索引碎片性能问题的第一步是确定问题有多大。运行sys.dm_db_index_physical_stats以分析碎片级别。然后决定是否重建索引、重组索引还是什么都不做。
重建：碎片超过30%时重建索引
重组：重组具有11-30%碎片的索引
忽略：10%或更少的碎片级别不会造成性能问题，因此无需执行任何操作
优化查询语句(QUERY)
数据库运行缓慢的其中一个原因是有我们写的QUERY造成的，所以需要优化查询语句。
无论是追溯调整查询语句以获得更好的数据库性能，还是从一开始就主动将其纳入，好的习惯将有助于确保查询快速准确地返回：
确定业务需求
避免 select *
使用INNERJOIN子句而不是WHERE子句创建连接
使用WHERE定义过滤器
避免使用前导 % 通配符
使用存储过程
批量进行删除和更新
