无限建站系统,电子商务网站的类型,wordpress阿里云主机,网站域名实名认证这段时间做一个SQL性能优化的案例分析#xff0c; 整理了一下过往的案例#xff0c;发现一个比较有意思的#xff0c;拿出来给大家分享。 这个项目是我在项目开展2期的时候才加入的#xff0c; 之前一期是个金融内部信息门户#xff0c; 里面有个功能是收集各个上市公司的… 这段时间做一个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秒内 符合了我们需要。 转载于:https://www.cnblogs.com/frankzye/p/5808909.html
