1. 请简述项目中优化sql语句执行效率的方法,从哪些方面,sql语句性能如何分析
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。
调整不良SQL通常可以从以下几点切入：
? 检查不良的SQL，考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器
2. 避免出现SELECT * FROM table 语句，要明确查出的字段。
3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。
4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。
5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。
6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。
7. 应绝对避免在order by子句中使用表达式。
8. 如果需要从关联表读数据，关联的表一般不要超过7个。
9. 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。
11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。
12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。
13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。
注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。
14. 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。
16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。
17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。
18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。
19. 用union all 代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。
当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。
2. 从哪些方面，sql语句性能如何分析
一段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条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。
3. mysql中sql性能分析方法有哪些
?Show
status
?一些值得监控的变量值：
?Bytes_received和Bytes_sent
?和服务器之间来往的流量。
?Com_*服务器正在执行的命令。
?Created_*在查询执行期限间创建的临时表和文件。
?Handler_*存储引擎操作。
?Select_*不同类型的联接执行计划。
?Sort_*几种排序信息。
?Show
session status like ‘Select’;
?Show profiles
?SET profiling=1;
?Show
profiles\G
?Show profile;
4. 如何测试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条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。
5. 如何使OQWT定位和分析SQL性能问题
封面报道
如何使用 IBM Optim Query Workload Tuner 定位和分析 SQL 性能问题 作者：秦玮, 刘铭, 赵国斌
IBM Optim Query Workload Tuner ( 简称 OQWT)， 是面向数据库管理人员和应用开发人员的新一代 SQL 性能调优产品，它可以对单个或者一组 SQL 查询语句进行性能分析和调优，包括 SQL 查询语句的定位、图形化的性能分析、多种的优化建议、验证优化方案等等。它提供了丰富的功能可以快速的从各种常用源找到有潜在性能问题的 SQL 语句。下面详细介绍如何使用 OQWT 快速定位问题 SQL 语句。
社区讨论精彩回顾：您如何看待使用数据库工具对DBA技术成长的影响?
本次讨论主要就以下几个问题进行了探讨：1、您如何看待使用数据库图形工具对DBA以及开发人员技术成长的影响? 2、您认为DBA们最常用的数据库工具是什么？ 3、您认为DBA们应该如何使用数据库工具才能高效的成长？
安装配置
AIX DB2 V8升级到DB2 V9.5的步骤 作者：DB2开发与应用社区 lijiantang
本文分操作系统升级与环境确认、停止相关系统应用、安装DB9数据库程序、备份相关配置文件等十个步骤向大家详细介绍了DB2数据库升级步骤。
性能调优
“三方演义”与性能优化 作者：DB2开发与应用社区 王飞鹏
本文作者自己实际的体会探讨了性能优化为什么这么难？并重点分析了某银行性能优化的真实案例。
故障诊断
对 DB2 远程 SQL 复制应用中的常见错误分析及处理 作者：黄湘平,张蕾
本文深入分析和刨析 SQL 复制的运行机制，列举出常见错误的处理方法，使 DB2 开发和管理人员能缩短处理问题的时间，提高他们在系统中应用 SQL 复制的效率。
博客精选
浅谈影响DB2高可用性的各种因素 作者：DB2开发与应用社区 sunyangnj
DB2数据库本身的设计和操作对高可用影响非常大。所以本文着重从DB2本身出发谈谈做好高可用应该注意的方面。
教程推荐
本栏目提供了DB2数据库的实用教程。
6. 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
7. 关于DB2 SQL语句的性能分析
记得DB2自带一个分析器,对SQL语句的运行次数(读数据库的次数)和时间进行统计,具体忘了
8. GBase 8a 如何开启trace日志，通过日志分析sql性能
set gbase_sql_trace =1
set global gbase_sql_trace_level=3,gbase_sql_trace_level 用于控制日志的详尽程度，分为
1~3 等几个不同级别，分析性能时建议设置为 3，可输出最为详尽的日志。
9. 如何分析sql server 2012数据库性能
sql server性能分析--查看表数据页数
返回表名、索引名和行数
SELECT object_name(i.object_id) as objectName, i.[name] as indexName, sum(p.rows) as rowCnt
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
返回表的总页数、使用页数、数据页数
SELECT object_name(i.object_id) as objectName, i.[name] as indexName,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as usedSpaceMB,
(sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
按页类型分类统计
SELECT case when grouping(i.object_id) = 1 then '--- TOTAL ---' else object_name(i.object_id) end as objectName,
case when grouping(i.[name]) = 1 then '--- TOTAL ---' else i.[name] end as indexName,
case when grouping(a.type_desc) = 1 then '--- TOTAL ---' else a.type_desc end as pageType,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as dataPages,
(sum(a.total_pages)
* 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as
usedSpaceMB, (sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.[name], a.type_desc with rollup