这段时间做一个SQL性能优化的案例分析， 整理了一下过往的案例，发现一个比较有意思的，拿出来给大家分享。
这个项目是我在项目开展2期的时候才加入的， 之前一期是个金融内部信息门户， 里面有个功能是收集各个上市公司的财报， 然后做各种分析， 数据图表展示， 使用的人数并不多， 仅百人左右。
2期打算面向行外用户， 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试， 结果在把1期的图表类数据展示响应基本在5分钟左右， 属于严重不可用， 说说我们的服务器配置， 有2台网站前端承载用户访问， 做F5负载均衡， 也就是说一台约25用户/秒的访问量， 有2台数据库做AlwaysOn。通过代码断点跟踪很快确定了性能瓶颈在数据库响应这一层。
既然确定了是数据库的性能问题， 接下来我们就准备开始对服务器的性能进行跟踪， 我们选取了常用的性能指标(内存，CPU，网络，硬盘IO)进行跟踪，然后跑我们的性能测试。
结果显示， CPU基本在测试的过程中是100%, 内存也占用了98%, 数据库硬盘IO的响应时间也超过了2分钟，内存指标是正常的， 由此我们可以得出几个假设:
数据库在不断进行TSQL语句编译，在高并发的情况下可能造成CPU占用率一直很高。
数据库有索引查询需要优化。
数据可能存在死锁
确实存在一些表存在大量数据的情况
事实上我们检查到程序员在编写代码的时候， 并没有利用到正确使用数据库变量，而是动态的生成T-SQL语句， 导致在高并发的时候， 频繁的进行语句编译，这印证了我们的第一点。
再进一步的我们通过Profiler工具找到响应时间较长的语句进行分析， 查看实际的执行计划， 优化了查询条件， 增加了索引，及查询条件优化
令我们意外的发现，是在某一时刻，进行简单的一个表进行查询， 也会长达数十分钟之久， 执行EXECUTE sp_lock， 查到其中一个应用程序正在使用insert into select from 批量插入数据到这一表中， 造成这一表读被锁定， 改用bulk insert解决了问题
1期也使用了一年中， 其实一些表的数据确实也已达到上亿的级别， 考虑到数据图表展示都是以一个月的数据为单位， 我们对这个表的数据进行了分区， 每个月的数据以单独的数据文件进行存储，实际上也取得了很好的效果。
最后在性能测试中， 我们的响应时间从原来的5分钟减少到2秒内， 符合了我们需要。
