在以前的工作经历中，虽然经历过高并发写入场景的GPS业务，却没有经历过ERP系统的复杂查询场景。最近接触的一个项目让我简隋英hi到了区别。
ERP项目，最典型的显然是读取场景要多得多，各种视图+函数+组合统计，让数据库读数据负载居高不下。甚至说找到这个系统慢的原因都反复不彻底。最近在这个项目我的经历如下，用的是SQL Server数据库：
1，数据库有死锁！
死锁是个严重的问题，赶紧看看什么场景。扫过表结构一看，居然没有用索引。各种查询集中在记账核心业务表上接二连三不间断，可不就是在争用锁嘛！
2，数据库表居然没有索引！
这一发现让我一上来就认为自己找到了问题所在，于是乎连续几天，翻查代码和视图，各种找where后面的条件，进行索引添加动作。然而问题来了，提升了不少，死锁问题也没在看到。自己各种页面看了一圈感受到了提升，本以为已经好了很多，喊了几个人一起测一下，还是慢。
3，集中查询导致的硬盘队列飙升！
由于看到了几个人同时做相同的操作时候会慢，一个人查询列表，另外2个人的写入都明显延迟。根据这一点现象，我盯着服务器硬盘看了下，队列动不动就飘到几十上百，这还了得！
应对办法，加缓存，屏蔽集中查询，几个人都打开同样的列表，那就干脆最近这几秒都是用同一个查询结果返回即可。
4，统计页面还是慢！
已经用了缓存，但是缓存只解决并发读问题，并没有真正解决计算量大问题，所以这时候我的注意力集中在了视图上，经过查阅了解到一个知识点：视图，表变量，表分区等使用，会导致系统数据库tempdb读写量巨大，回到磁盘监控看了下果然是，读写最多的就是tempdb，而且磁盘队列高的时候几乎一定是tempdb排在第一个。
这里难度就大了，可能真得动代码结构了，前面的查询几乎没写过几行代码。这一步看来逃不过了。老老实实逐个看代码吧，果然各种统计都是直接用的视图，更要命的是都是时间入参动态统计所有，动辄就要使用几十万源数据进行表关联。这一步就没法偷懒了，我去改代码了，没时间写博客了。。。。
原文地址：
https://www.opengps.cn/Blog/View.aspx?id=931
文章的更新编辑依此链接为准。欢迎关注源站原创文章！