4、 在您的SQL Server使用过程中，有哪些令您非常困惑的性能问题 ?
讨论汇总——综合
l Tempdb方面的问题
a） 行级和事务级的快照都存储在TEMPDB中 (不知架构为什么设计成这样),UNDO \ REDO 自然不太方便
b） tempdb放了太多的功能，带来性能瓶颈
个人观点： tempdb感觉确实是个瓶颈。每个版本几乎都会往tempdb里面多放一些东西，tempdb所承担的东西是越来越多
l 配置方面的问题
a） DBA调整方面能够做的事情不多，内存调整只有2个参数
b） I/O调整，除了文件级的分离，DBA还能做哪些事情
c） 似乎MSSQL DBA能够做的性能调整就是维护计划，索引优化和统计信息 碎片整理，SQL语句级别调整
d） 内存方面，可控性太少了，划了块大内存后，其他的DBA都干不了了
e） 性能调整方面。MSSQL给DBA的空间比较小
个人观点： 配置参数的多少这个不太好说，SQL Server还有不少配置项是没有在官方文档上公开说明的；在实际应用中，感觉基本上需要调整的配置项不是太多，不做配置也基本上能够适应大部分情况（自动配置方面做得还是不错）；至于DBA的日常工作，只要能够使用合适的方法保障服务器的性能和稳定，并且有合适的措施去预防重复故障的发生就基本达到目标了。至于DB方面是否提供了对应的支持，这个只能具体问题具体分析，有可能是没有提供，也有可能是你没有找到
l 负载均衡。貌似SQLServer上没什么好的方案吧
个人观点：Always on应该算是迈进了一大步，但确实是没有完备的方案
l DB LINK，貌似不会走索引，在涉及跨库的时候大数据时，比较纠结
个人观点：会走索引，但限制性比实例内要高；在实例内，查询优化器会尽可能解析对象到基础对象，并获取得评估查询成本相关的信息；对 DB lINK，其获取查询成本评估信息的对象就是查询的对象，如果查询的是表，自然可以获取到相碰的信息，如果不是非索引视图，则是没有索引、统计信息这类对查询成本评估很有帮助的信息可获取，自然就无法走索引
l 生产环境镜像与复制并存，而mirror的性能似乎不高，经常出现延迟现象，查看wait event，总是镜像方面的等待事件占多
个人观点：可以通过镜像监视器或者镜像相关的动态视图、性能指标，进一步确定延迟的点，以确定可行的改进
l 千万级大表的排序聚合操作性能尤其低，这方面优化比较困难，目前除了合理索引，大表分区和读写分离建立独立的report server外，没有更好的方法
个人观点：大量数据的聚合应该是要在常规查询中避免的，比如你可以用Job定时把把历史数据聚合写入到聚合表，这样查询只需要聚合未聚合的部分，再UNIONALL已经聚合的数据就可以了；创建包含聚合数据的索引视图，也是一个可行的解决方法（对数据的变更效率会有一定的影响）。另外，通常应该考虑将OLTP和OLAP任务分离
l 发布订阅大并发。大DML量很容易导致死锁，简单的读写分离是我多年心头的痛
个人观点：包含发布的数据库，如果短时间内有表做过大量的数据变更，确实会导致一些问题。复制的日志读取器需要花大量时间去读出这些日志，并提取和生成需要发布的命令；如果被更改的是发布的表，并且分发与发布是共用一个实例的话，分发的压力也会对服务器造成压力；而且复制的命令是记录级（行级）的，所以大量的数据变更的同步周期也会比较长。对于大量数据变更，在可行的情况下，可以考虑勇冠复制存储过程的方式来解决；如果数据变更已经执行，重新同步那些产生了巨大数据变化的表可能是一个解决问题的方法
l 以前遇到一个情况是，加上forceorder后1秒内出结果；去掉force order要15秒
个人观点：可能是统计信息不准，或者是条件包含像变量这种无法确定值的情况，导致查询优化器评估的成本不准
l 一个SQL的Instance下，数据库不断在增加，每个数据库都不太大……长期下去3000个数据库都估计达到的情况下，会不会有性能瓶颈？
个人观点：容易出来性能瓶颈，最常见的可能会是tempdb资源的银用，毕竟每个实例只有一个tempdb，而且很多内部的东东都或多或少会用到tempdb；第2个可能会争用的资源可能是连接资源；另外，管理上可能也会受到影响，比如Job、Login可能会多而且不太容易管理
l 往往查询最多的表，就是更新最频繁的表。更新最多的字段，也是查询最多的字段。典型的例子是订单表。订单表在不断insert，订单状态字段在不断update。另一方面，订单表在不断被查询，例如当前日期下，已下单未发货的订单详情，已发货未付款的订单详情等等，我们的系统里，这个订单查询界面，都是只要它被打开，就有线程每5秒钟刷新一次最新订单状况。注意每一个客户端每5秒刷新一次。同时在线的用户如果上千个，等于这个表每秒都在刷新了。请问这种情形，大家有什么好的建议？
个人观点：考虑读写分离。另外，考虑程序设计是否合理，比如5秒钏刷新一次的频率是为了100%满足用户需求，1分钟刷新一次是否可以满足90%的需求，如果可以的话，是否一定要满足到100%？手段上，DB数据刷新访问是否可以由一个服务统一控制？如果在同一时间有5个客户端调用这个服务，那么服务只需要取一次数据，分发给5个客户端就行，没必要每个客户端独立去访问DB；更进一步的，是否可以为数据变更设置标志，使用增量的拉数据的方式？
l 在对很大的表做分区merge操作或者重建索引时, 服务器的cpu使用率很低,，而从sysprocesses中查询到进程的等待类型又是 sos_scheduler_yield，不理解为什么会这样.
个人观点：可以看看各个CPU的任务分配，看是否是因为分配差异太大导致（某一两个CPU使用率高，其他空闲）SELECT scheduler_id , current_tasks_count, runnable_tasks_countFROM sys.dm_os_schedulers WHERE scheduler_id < 255
l 其他一些SQLserver的时候困扰的因素包括
a） 新版耗内存,CPU处理能力跟不上，磁盘不够大，使得原来旧设备性能到了瓶颈，结果只有一个：退役，更换设备，导致成本增加，设备不能更好的合理利用
b） 新版sqlserver虽然增加了列索引，但也存在索引性能的瓶颈
c） 数据库作业性能瓶颈
d） 低效率的SQL语句导致数据库整体性能降低
e） T-SQL性能的瓶颈
f）高并发，需求不稳定，突兀的谷峰交易对数据库和应用的冲击最大
g） CPU占用率高的现象比较多，降低了又会上去
个人观点：新的东西确实会对硬件有更新的要求，毕竟其设计基础与旧版本是不一样的，根据需要选择合适的版本即可，并不是最新的就一定是最适合的。性能问题，需要一个跟踪分析的过程，确定清楚原因才能找到有效的解决方案
1571
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
