⑴ sql Server 与 MySQL 性能相差多大
sql server性能优于mysql。测试，一个表三千万数据，模糊查找，主键查找，插入sqlerver所用时间不足mysql一半。均为默认安装。模糊查找，mysql55秒左右，sqlerver 25秒左右。
⑵ 怎样查出SQLServer的性能瓶颈
SQLServer性能监控
这套性能优化的清单将至少准科学的帮助你找出你的SQLServer任何明显的性能问题。说是这样说，SQLServer的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的sqlserver性能问题，困难的留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能调优范围，就很容易的将这些问题解决，一旦解决了这些容易的问题，那么你就能集中去解决更困难的问题。
使用这个SQLServer性能调优清单的一个好处是，它将不仅仅告诉你目前最容易解决的性能问题是什么，而且还帮助你正确的去解决。在某种程度上，你可以选择不同的顺序进行。换句话说，你可以故意做出特殊的决定而不是按照清单通常的顺序进行。某种意义上说你是对的，不是所有的性能调优建议都适合所有的情形。另外，你的决定是基于你的资源限制，例如没有足够的钱去买满足负荷的硬件。如果真是那样的话，你就别无选择了。还有，你的决定可能基于一些政治原因，那是你不得不作出的改变。不管怎样，你需要知道你能做什么，使用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQLServer的性能。
一般来说，你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题，这会花掉你一些时间。我建议你从目前性能问题最多的的服务器开始，然后当你有时间的时候按照自己的思路去解决其他服务器。
一旦你完成了，可仍然有很多事情要去做。记住，这些只是一些容易的。一旦你完成了这些容易的，接下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。
怎样进行你的SQLServer性能调优呢?
为了使其变得容易，我把它们分成了以下几个部分：
？ 使用性能监视器找出硬件瓶颈
？ SQLServer硬件性能监控列表
？ 操作系统性能监控列表
？ SQLServer2000配置性能监控列表
？ 数据库配置设置性能监控列表
？ 索引性能监控列表
？ 应用程序和T-SQL性能监控列表
？ SQLServer数据库作业性能监控列表
？ 使用Profiler找出低效的查询
？ 怎样最好的实现SQLServer性能监控
管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容，把它们打印出来。然后完成每一部分的内容，写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序，因为那样通常能达到一个比较好的效果。
性能监控列表
计数器名称 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections
在上表输入你的结果.
使用性能监视器找出SQLServer硬件瓶颈
开始SQLServer性能调优的最佳地方就是从性能监视器（系统监视器）开始。通过一个24小时的周期对一些关键的计数器进行监控，你将对你SQLServer服务器的硬件瓶颈了如指掌。
一般来说，使用性能监视器去创建一个一些关键的计数器的24小时周期的监控日志。当你决定创建这个日志的时候，你需要选择一个典型的24小时的周期，例如，选择一个典型的比较忙的日期，而不是周日或节假日。
一旦你将这些捕获的数据形成日志后，在性能监视器的图形界面下会显示计数器的推荐值。你在上表中记下均值、最小值、峰值。做完这些后，用你的结果跟下面的分析比较。通过你的结果和下面的建议值进行比较，你将能快速的找到你的SQLServe正在经历的潜在的硬件瓶颈。
关键性能计数器说明
下面是不同关键性能计数器的一个讨论，它们的建议值和为了帮助解决硬件瓶颈问题的一些选项。注意我已经限制了性能监视器需要监视的一些关键计数器。我这么做是因为在本文我们的目的是为了容易的找到显而易见的性能问题，许多其他的性能监视器计数器你能在本网站其他地方找到。
Memory: Pages/sec
这个计数器记录的是每秒钟内存和磁盘之间交换的页面数。交换更多的页面、超过你服务器承受的更多的I/O，将轮流降低你SQLserver的性能。你的目的就是尽量将页面减少到最小，而不是消除它。
如果你的服务器上SQLServer是最主要的应用程序，那么这个值的理想范围是0～20之间。可能很多时候你看到的值都会超过20。这个值一般要保持在每秒的平均页数在20以下。
如果这个值平均总是超过20，其中最大的一个可能是内存瓶颈问题，需要增加内存。通常来说，更多的内存意味着需要执行的页面更少。
在大多数情况下，服务器决定SQLServer使用的适当内存的大小，页面将平均小于20。给SQLServer适当的内存意味着服务器的缓存命中率（Buffer Hit Cache Ratio 这个稍后会讲到）达到99％或者更高。如果在一个24小时的周期里你的sqlserver的缓存命中率达到99％或者更高，但是在这个期间你的页面数总是超过20，这意味着你或许运行了其他的程序。如果是这样的情况，建议你移除这些程序，使SQLServer是你的服务器的最主要的程序。
如果你的sqlserver服务器没有运行其他程序，并且在一个24小时的周期里页面数总是超过20，这说明你应该修改你对SQLServer的内存设置了。将其设置为“动态配置SQLServer的内存”，并且最大内存设置得高一些。为了达到最优，SQLServer将尽可能的获得多的内存以完成自己的工作，而不是去和其他的程序争夺内存。
Memory: Available Bytes
另一个检查SQLServer是否有足够的物理内存的方法是检查Memory Object: Available Bytes计数器。 这个值至少大于5M，否则需要添加更多的物理内存。在一个专门的SQLServer服务器上，SQLServer试图维持4-10M的自由物理内存，其余的物理内存被操作系统和SQLServer使用。当可用的物理内存接近5M或者更低时，SQLServer最可能因为缺少内存而遇到性能瓶颈。遇此情况，你需要增加物理内存以减少服务器的负荷，或者给SQLServer配置一个合适的内存。
Physical Disk: % Disk Time
这个计数器度量磁盘阵列繁忙程度（不是逻辑分区或磁盘阵列上独立的磁盘）。它提供一个对磁盘阵列繁忙程度相对较好的度量。原则上计数器% Disk Time的值应该小于55%。如果持续超过55%（在你24小时的监控周期里大约超过10分钟），说明你的SQLServer有I/O瓶颈。如果你只是偶尔看到，也不必太担心。但是，如果经常发生的话（也就是说，一个小时出现好几次），就应该着手寻找增加服务器I/O性能或者减少服务器负荷的解决之道了。一般是为磁盘阵列增加磁盘，或者更好更快的磁盘，或者给控制器卡增加缓存，或者使用不同版本的RAID，或者更换更快的控制器。
在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。
Physical Disk: Avg. Disk Queue Length
除了观察物理磁盘的% Disk Time计数器外，还可以用Avg. Disk Queue Length计数器。磁盘阵列中的各个磁盘的该值如果超过2（在你24小时的监控周期里大约超过10分钟），那么你的磁盘阵列存在I/O瓶颈问题。象计数器% Disk Time一样，如果只是偶尔看到，也不必太担心。但是，如果经常发生的话，就应该着手寻找增加服务器I/O性能的解决之道了。如前所述。
你需要计算这个值，因为性能监视器不知道你的磁盘阵列中有多少物理磁盘。例如，如果你有一个6个物理磁盘组成的磁盘阵列，它的Avg.
Disk Queue Length值为10，那么实际每个磁盘的值为1.66（10/6＝1.66），它们都在建议值2以内。
在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。
一起使用这两个计数器将帮助你找出I/O瓶颈。例如，如果% Disk Time的值超过55%，Avg. Disk Queue Length计数器值超过2，服务器则存在I/O瓶颈。
Processor: % Processor Time
处理器对象： % Processor Time计数器对每一个CPU可用，并针对每一个CPU进行检测。同样对于所有的CPU也可用。这是一个观察CPU利用率的关键计数器。如果% Total Processor Time计数器的值持续超过80%（在你24小时的监控周期里大约超过10分钟），说明CPU存在瓶颈问题。如果只是偶尔发生，并且你认为对你的服务器影响不大，那没问题。如果经常发生，你应该减少服务器的负载，更换更高频率的CPU，或者增加CPU的数量或者增加CPU的2级缓存（L2 cache）。
System: Processor Queue Length
根据% Processor Time计数器，你可以监控Processor Queue Length计数器。每个CPU的该值如果持续超过2（在你24小时的监控周期里大约超过10分钟），那么你的CPU存在瓶颈问题。例如，如果你的服务器有4个CPU，Processor Queue Length计数器的值总共不应超过8。
如果Processor Queue Length计数器的值有规律的超过建议的最大值，但是CPU利用率相对不是很高，那么考虑减少SQLServer的"max worker threads"的配置值。Processor Queue Length计数器的值高的可能原因是有太多的工作线程等待处理。通过减少"maximum worker threads"的值，强迫线程池踢掉某些线程，从而使线程池得到最大的利用。
一起使用计数器Processor Queue Length和计数器% Total Process Time，你可以找到CPU瓶颈，如果都显示超过它们的建议值，可以确信存在CPU瓶颈问题。
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server Buffer中的计数器Buffer Cache Hit Ratio用来指出SQLServer从缓存中而不是磁盘中获得数据的频率。在一个OLTP程序中，该比率应该超过90%，理想值是超过99%。如果你的buffer cache hit ratio低于90%，你需要立即增加内存。如果该比率在90%和99%之间，你应该认真考虑购买更多的内存了。如果接近99%，你的SQLServer性能是比较快的了。某些情况下，如果你的数据库非常大，你不可能达到99%，即使你在服务器上配置了最大的内存。你所能做的就是尽可能的添加内存。
在OLAP程序中，由于其本身的工作原理，该比率大大减少。不管怎样，更多的内存总是能提高SQLServer的性能。
SQL Server General: User Connections
既然sqlserver的使用人数会影响它的性能，你就需要专注于sqlserver的General Statistics Object: User Connections计数器。它显示sqlserver目前连接的数量，而不是用户数。
如果该计数器超过255，那么你需要将sqlserver的"Maximum Worker Threads" 的配置值设置得比缺省值255高。如果连接的数量超过可用的线程数，那么sqlserver将共享线程，这样会影响性能。"Maximum Worker Threads"需要设置得比你服务器曾经达到的最大连接数更高。
⑶ SQL Server 与 MySQL 性能相差多大
如果只是基本简单的存储和利用没有太大区别，但是请注意：现在数据库的国际化指标基本还是三种：Oracle/SQLServer/DB2；
顺便说说我自己目前理解的sqlserver比mysql好的地方：
函数，sqlserver很多函数mysql没有，或者说有但没有前者直接明了
关联关系，sqlserver可以和其他数据库关联，包括oracle等
大数据处理，这个绝对是肯定的
查询或者说数据处理优化
其他的我就不清楚了
⑷ MySQL和SQLServer相比，哪个性能更好
MySQL和SQLServer相比，哪个性能更好
主要差别，SQL Server是微软的，只在Windows里能用。MySQL，各种操作系统都能用。要说性能，Sun公司已经把MySQL做到很好了，可以支持大型系统。但是Oracle以后会不会把MySQL做到能够威胁Oracle数据库的程度，就不知道了。
⑸ spotlight on sql server具体监控哪些参数指标
你要闲着没事，系统的性能监控器里sql server的每个参数都可以看看啊，这要写可以写一本书了。
系统
内存: 可用字节数，page\sec
processor: processor time
physical disk:disk time
需要的话还有网络流量
至于sqlserver的监控，至少有
full scans/sec
cache hit ratio
transaction/sec
user connection
lock
number of dead lock/sec
query...
⑹ 如何测试sqlserver性能
对于DBA来讲，我们都会做新服务器的性能测试。我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。
下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。
自己写负载测试代码很困难
为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。你不想总是对单一行更新相同的值，或者只是重复插入假的值。
自己动手使用Powershell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。
免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载
HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。你可以使用HammerDB来针对一个数据库生成脚本并导入测试。HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。
首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。你也可以用它来模拟用于示范或研究目的的不同负载。
用于SQL Server上的HammerDB的优缺点
HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。它的自动程序特性也是的运行工作负载相当自动。
主要缺点是它有一个学习曲线。用户界面不是很直观，需要花费时间去习惯。再你使用这个工具一段时间之后，将会更加容易。
HammerDB也不是运行每一个基准测试。它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。但是，它是免费的、快速的、易用的。
基准测试使用案例
基准测试负载不能精确模拟你的应用程序的特点。每个负载是唯一的，在不同的系统有不同的瓶颈。对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：
多个环境（例如：旧的物理服务器，新的虚拟环境）
使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）
在配置改变前后的点
当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。
对于自学和研究来说，有预配置的负载非常棒。
开始使用基准测试
你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。
⑺ sqlserver 中一些常看的指标和清除缓存的方法
如何查看磁盘I/O操作信息
SET
STATISTICS
IO
ON
命令是一个
使
SQL
Server
显示有关由
Transact-SQL
语句生成的磁盘活动量的信息。
我们在分析索引性能的时候，会非常有用。
启用了这个属性后，我们在执行
SQL
语句后，会收到类似如下的信息，这有利于我们分析SQL的性能：
(3999
row(s)
affected)
表
'ChargeCL'。扫描计数
1，逻辑读取
9547
次，物理读取
0
次，预读
0
次，lob
逻辑读取
0
次，lob
物理读取
0
次，lob
预读
0
次。
其中的
lob
逻辑读取、lob
物理读取、lob
预读
这三个指标是
读取
text、ntext、image
或大值类型
(varchar(max)、nvarchar(max)、varbinary(max))
时的指标。
而
逻辑读取、物理读取、预读
是对普通数据页的读取。
使用
SQL
Server
Management
Studio
Standard
Reports
我们在
SQL
Server
Management
Studio
中，选择数据库服务器，或者具体数据库，或者Security
--
Logins
时，或者Management
时，Notification
Services
或者
SQL
Server
Agent
对象时候，都会看到SQL
Server
替我们提供的一些现成报表，这些报表的数据，有利于我们分析数据库的状态。
比如在
SQL
Server
索引基础知识(1)---
记录数据的基本格式
http://blog.joycode.com/ghj/archive/2008/01/02/113290.aspx
中，我们就使用数据表占用空间的报表
具体报表可以参考以下链接：
SQL
Server
Management
Studio
Standard
Reports
-
Overview
http://blogs.msdn.com/buckwoody/archive/2007/10/09/sql-server-management-studio-standard-reports-overview.aspx
测试中，释放缓存的一些方法
尤其查询语句性能测试时，数据是否被缓存，这是测试中一个重要点。下面几个命令帮助我们清除缓存。方便测试。
清除缓存有关的命令：
SQL
2000里面除了dbcc
unpintable好像就没有了
而且这个操作也不会立即释放表内存Buffer
(DBCC
UNPINTABLE
does
not
cause
the
table
to
be
immediately
flushed
from
the
data
cache.
It
specifies
that
all
of
the
pages
for
the
table
in
the
buffer
cache
can
be
flushed
if
space
is
needed
to
read
in
a
new
page
from
disk.)
SQL
2005/2008让DBA能够更自由的对SQL所占用的内存空间做处理
如：
CHECKPOINT
将当前数据库的全部脏页写入磁盘。“脏页”是已输入缓存区高速缓存且已修改但尚未写入磁盘的数据页。CHECKPOINT
可创建一个检查点，在该点保证全部脏页都已写入磁盘，从而在以后的恢复过程中节省时间。
DBCC
DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
DBCC
FREEPROCCACHE
从过程缓存中删除所有元素。
DBCC
FREESYSTEMCACHE
从所有缓存中释放所有未使用的缓存条目。SQL
Server
2005
数据库引擎会事先在后台清理未使用的缓存条目，以使内存可用于当前条目。但是，可以使用此命令从所有缓存中手动删除未使用的条目。
另外还可以
sp_cursor_list
查看全部游标
DBCC
OPENTRAN查看数据库打开事务状态等
⑻ 【查询优化】怎样用SQL语句查看查询的性能指标
（有关TSQL语句查询所产生的磁盘活动量） --显示有关由Transact-SQL 语句生成的磁盘活动量的信息 SET STATISTICS IOON--关闭有关由Transact-SQL 语句生成的磁盘活动量的信息 SET STATISTICS IOOFF 显示的信息如下： （SQL语句为：select * fromnote500）其中： 扫描计数：在查询中涉及到的表被访问的次数； 逻辑读取：从数据缓冲中读取的数据页数； 物理读取：从物理磁盘中往缓冲读取的数据页数； 预读：根据执行计划从物理磁盘中往缓冲读取的数据页数； 其中对于首次查询一般情况下会有一下关系：逻辑读取=物理读取+预读(其中的具体联系，由于已经在之前的博客文章中提到，就不再详细说明（文章名为 【查询优化】MSSQL查询执行流程）) 同理，后面的lob逻辑读取、物理读取、预读概念理解差不多，只是是对相应表进行更新或插入操作时体现。 对于扫描计数，以上图片的查询没有连接查询，因此意义不大。不过，如果连接查询来说，特别是循环查询那种，比如说自连接，如果循环次数越多，则扫描次数也就越多，则会使得查询的效率越低。这是扫描计数是一个比较重要的性能体现参数。 对于逻辑读取，由于SQLSERVER中对数据进行任何操作都要把数据读入到缓冲当中，如果逻辑读取的页数越多，则查询的性能越低。为此，逻辑读取一般都是查询性能体现的一个重要参数。 二、SET STATISTICSTIME（SQL Server解析和编译时间） 上面显示的信息表明，执行这次查询使用了多少CPU运行时间和运行查询使用了多少时间。CPU运行时间是对运行查询所需要的CPU资源的一种相对稳定的测量方法，与CPU的忙闲程度没有关系。但是，每次运行查询时这一数字也会有所不同，只是变化的范围没有总时间变化大。总时间是对查询执行所需要的时间（不计算阻塞或读数据的时间），由于服务器上的负载是在不断变化的，因此这一数据的变化范围有时会相当地大。 总的来说，量化地来看一个查询语句的性能可以在几个参数进行比较： 1、CPU时间。比较查询所要占用的CPU资源时间； 2、I/O。可以比较查询的循环扫描次数和逻辑读取的数据量；