【IT168 技术文章】

    常见的性能问题

    1.最重要的性能问题是应用程序设计及与数据库的交互
    应用程序设计：好的应用程序设计可能会获得优秀的响应时间（但不能确保），但差的应用程序设计很难获得好的性能。差的性能设计比如：不管怎么操作，让用户检索出大量结果集（比如50M）的程序运行效率不会高，大量数据的延迟会很明显。
    2.数据库设计
    物理和逻辑设计，涉及非常多的方面，俺也不懂，举一个简单的例子：一个测试问题，大数据量下列表展现（多表联合查询）问题不能满足性能需求。DBA修改了数据库设计采用汇总表去展现列表（单表查询），汇总表也方便创建索引。
    3.参数调整
    4.硬件环境（包括网络对性能的影响会比较大）
    5.其他，因素很多。

    就几个常见的性能问题，举例展开，性能问题非常多，也总结不全面，但可以经常回顾，分类汇总，逐步完善性能问题总结这部分工作。

    一、数据库交互过多

    ?       现象：单个操作发送给数据库sql的数据量过多，数据库延迟。

    ?       发现方法：采用监控工具分析程序与数据库的交互（sql数量和响应时间），比如P6spy及类似工具。

    ?       数据库交互与程序设计方式息息相关

    建议使用P6spy帮助去做数据库交互分析,截获页面操作的sql。

    二、列表效率低

    ?       列表查询未使用索引。

    ?       查询全部字段，而不是所需字段，带来额外的I/O和网络负担。

    ?       分页算法效率低，甚至未使用分页。

    1.查询未使用索引
    此问题比较常见，通过查看sql的执行时间和I/O。查看查询计划可以清楚看出sql是否索引查询，或者全表扫描
     select  ID  。。 from B   where xxx        
    2. 比如 Select xxx  from  where  UPPER(name)＝‘A’
    在字段上使用函数，导致不使用索引，虽然Oracle是有基于函数的索引。更好的方式  a.update现有数据  b.改程序，直接改存储模式为大写的数据。
    3.冗余字段的优化
    select  。。。    from A   where 。。。。比如 where 条件查询的字段的长度较大，创建索引效果后不明显，考虑增加了冗余的字段，进行标识，结合在冗余字段上创建索引会比较快。
    4.分页算法,遇到的状况也比较混乱。。。。。好的分页算法要推广，公用。

    三、查询结果集过大

    ?       返回全部的数据（建议从业务角度出发，分析返回全部的数据是否必要）

    ?       空查询（默认条件查询）
   
    ?       不规范的查询（where 1＝1）

    1.查询结果集（建议从业务角度优化系统）
    2.空查询（默认查询造成压力比较大，其实空查询可能是没有必要的）
    建议页面增加默认过滤条件
    3.Where 1＝1
    a、性能上的影响（可能会影响orale的查询计划）
    b、安全性的影响
    create table A tablespace tbs_temp as  select * from B where 1<>1
    create table A  as  select * from B where 1<>1
    Sybase不支持这样的语法，但是有：
    select * into A from B where 1 <> 1
    where 1 <> 1 ，复制表的结构，但注意这样没有主键
    4.不规范的查询sql很多，建议多参考部门的相关规范，从规范的角度出发去发现问题。

    四、复杂查询sql （大数据量测试）

    ?       复杂查询sql一定在大数据量下进行测试

    ?       结合操作和sql本身效率进行测试。

    ?       建议多与DBA配合

    如果你只使用小表进行测试（比如小于100条数据），那么在真实数据下会异常缓慢直至停滞。Sql的例子就不列出了，比较多，通常对于多表联合查询，复杂的sql都要在大数据量下测试。其实越复杂的东西越难维护和优化，建议对系统中复杂的sql都记录下来，可能是性能隐患。