sql性能测试

A. PL/sql怎么测试一个sql语句的性能

plsql developer吗？

用F5，查看sql语句的查询计划

针对全表扫描、索引扫描等部分进行优化。

B. 检查SQL语句性能

exlpain sql语句

C. 如何测试sql语句性能，提高执行效率

有时候我们经常为我们的sql语句执行效率低下发愁，反复优化后，可还是得不到提高

那么你就用这条语句找出你sql到底是在哪里慢了

示例：
SET STATISTICS io ON
SET STATISTICS time
ON
go
---你要测试的sql语句
select top 100 * from
TBL_Cot_RecStaticList
go
SET STATISTICS profile
OFF
SET STATISTICS io OFF
SET STATISTICS time OFF
显示信息：

SQL Server 分析和编译时间:

CPU 时间 = 0 毫秒，占用时间 = 59 毫秒。

(100 行受影响) 表 'TBL_Cot_RecStaticList'。扫描计数 1，逻辑读取 14 次，物理读取 2
次，预读 992 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

SQL Server 执行时间: CPU 时间 = 0 毫秒，占用时间 = 306 毫秒。

SQL Server 分析和编译时间: CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间: CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间: CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

D. 如何使用MySQL自带的性能压力测试工具mysqlslap

使用--auto-generate-sql参数表示用mysqlslap工具自己生成的SQL脚本来测试并发压力
mysqlslap --auto-generate-sql -uroot -p123456

并发测试，使用–concurrency来模拟并发连接，连接数可以多个，用逗号隔开
mysqlslap --auto-generate-sql --concurrency=100 -uroot -p123456
mysqlslap --auto-generate-sql --concurrency=50,100 -uroot -p123456

使用--iterations模拟迭代测试，用于需要多次执行测试得到平均值。
mysqlslap --auto-generate-sql --iterations=5 -uroot -p123456

使用--engine测试不同的存储引擎的性能进行对比
mysqlslap --auto-generate-sql --concurrency=50,100 --iterations=5 --engine=myisam,innodb -uroot -p123456

--query=name,-q 指定自定义脚本执行测试，例如可以调用自定义的一个存储过程或者sql语句来执行测试。--create-schema 指定自定义的测试数据库名称，
mysqlslap --auto-generate-sql --concurrency=50,100 --create-schema="landclash" --query="call landclash.sp_player_getname(34);" --number-of-queries=5000 -uroot -p123456

E. 如何测试sql语句性能，提高执行效率，sql2008

一段SQL代码写好以后，可以通过查看SQL的执行计划，初步预测该SQL在运行时的性能好坏，尤其是在发现某个SQL语句的效率较差时，我们可以通过查看执行计划，分析出该SQL代码的问题所在。 1、 打开熟悉的查看工具：PL/SQL Developer。 在PL/SQL Developer中写好一段SQL代码后，按F5，PL/SQL Developer会自动打开执行计划窗口，显示该SQL的执行计划。 2、 查看总COST，获得资源耗费的总体印象 一般而言，执行计划第一行所对应的COST(即成本耗费)值，反应了运行这段SQL的总体估计成本，单看这个总成本没有实际意义，但可以拿它与相同逻辑不同执行计划的SQL的总体COST进行比较，通常COST低的执行计划要好一些。 3、 按照从左至右，从上至下的方法，了解执行计划的执行步骤 执行计划按照层次逐步缩进，从左至右看，缩进最多的那一步，最先执行，如果缩进量相同，则按照从上而下的方法判断执行顺序，可粗略认为上面的步骤优先执行。每一个执行步骤都有对应的COST,可从单步COST的高低，以及单步的估计结果集（对应ROWS/基数），来分析表的访问方式，连接顺序以及连接方式是否合理。 4、 分析表的访问方式 表的访问方式主要是两种：全表扫描（TABLE ACCESS FULL）和索引扫描(INDEX SCAN)，如果表上存在选择性很好的索引，却走了全表扫描，而且是大表的全表扫描，就说明表的访问方式可能存在问题；若大表上没有合适的索引而走了全表扫描，就需要分析能否建立索引，或者是否能选择更合适的表连接方式和连接顺序以提高效率。 5、 分析表的连接方式和连接顺序 表的连接顺序：就是以哪张表作为驱动表来连接其他表的先后访问顺序。 表的连接方式：简单来讲，就是两个表获得满足条件的数据时的连接过程。主要有三种表连接方式，嵌套循环（NESTED LOOPS）、哈希连接（HASH JOIN）和排序-合并连接（SORT MERGE JOIN）。我们常见得是嵌套循环和哈希连接。 嵌套循环：最适用也是最简单的连接方式。类似于用两层循环处理两个游标，外层游标称作驱动表，Oracle检索驱动表的数据，一条一条的代入内层游标，查找满足WHERE条件的所有数据，因此内层游标表中可用索引的选择性越好，嵌套循环连接的性能就越高。 哈希连接：先将驱动表的数据按照条件字段以散列的方式放入内存，然后在内存中匹配满足条件的行。哈希连接需要有合适的内存，而且必须在CBO优化模式下，连接两表的WHERE条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。

F. 百万数据下几种SQL性能测试

由于在参与的实际项目中发现当mysql表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。曾经测试对一个包含400多万条记录（有索引）的表执行一条条件查询，其查询时间竟然高达40几秒，相信这么高的查询延时，任何用户都会抓狂。因此如何提高sql语句查询效率，显得十分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法：
1、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

2、对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0

G. 如何进行SQL性能优化

这里分享下mysql优化的几种方法。

1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。

H. 数据库性能测试跟普通的性能测试有什么区别

很明显，一个是针对数据库进行测试，主要检查sql语句的优化、索引等等；
普通性能测试针对的比较多，被测系统（内存溢出、泄露等问题）、应用服务器、数据库、硬件等等

I. 如何做SQL Server性能测试

对于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”开始。

J. 如何测试sqlserver性能

1、打开sql server studio management
2、打开"工具"-"sql server profiler"
3、点击连接
4、点击运行
5、可以看到捕捉到的一些访问数据库的事件，其中有读写，点用cpu，持续时间等信息可以参考
6、点击某个事件，可以查看具体执行了什么sql脚本，进一步分析相关逻辑