标签 : 3个相关结果 42次浏览

oracle wm_concat(column)函数使我们经常会使用到的,下面就教您如何使用oracle wm_concat(column)函数实现字段合并,如果您对oracle wm_concat(column)函数使用方面感兴趣的话,不妨一看。 shopping: —————————————– u_id       goods            num —————————————— 1                苹果                2 2                 梨子               5 1                 西瓜               4 3                 葡萄               1 3                香蕉                1 1               橘子                 3 ======================= 想要的结果为: ——————————– u_id          goods_sum ____________________ 1              苹果,西瓜,橘子 2              梨子 3              葡萄,香蕉 ——————————— select u_id, wmsys.wm_concat(goods) goods_sum     from shopping     group by u_id   想要的结果2: ——————————– u_id          goods_sum ____________________ 1              苹果(2斤),西瓜(4斤),橘子(3斤) 2              梨子(5斤) 3              葡萄(1斤),香蕉(1斤) ——————————— 使用oracle wm_concat(column)函数实现: select u_id, wmsys.wm_concat(goods || ‘(‘ || num || ‘斤)’ ) goods_sum     from shopping     group by u_id    

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化。 为了获得稳定的执行性能,SQL语句越简单越好。对复杂的SQL语句,要设法对之进行简化。 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN) 2)考虑使用临时表或表变量存放中间结果。 3)少用子查询 4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜。 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制。 最好是把连接拆开成较小的几个部分逐个顺序执行。 优先执行那些能够大量减少结果的连接。 拆分的好处不仅仅是减少SQL Server优化的时间,更使得SQL语句能够以你可以预测的方式和顺序执行。 如果一定需要连接很多表才能得到数据,那么很可能意味着设计上的缺陷。 连接是outer join,非常不好。因为outer join意味着必须对左表或右表查询所有行。 如果表很大而没有相应的where语句,那么outer join很容易导致table scan或index scan。 要尽量使用inner join避免scan整个表。 优化建议: 1)使用临时表存放t1表的结果,能大大减少logical reads(或返回行数)的操作要优先执行。 仔细分析语句,你会发现where中的条件全是针对表t1的,所以直接使用上面的where子句查询表t1,然后把结果存放再临时表#t1中: Select t1….. into #tt1 from t1 where…(和上面的where一样) 2)再把#tt1和其他表进行连接: Select #t1… Left outer join … Left outer join… 3)修改 like 程序,去掉前置百分号。like语句却因为前置百分号而无法使用索引 4)从系统设计的角度修改语句,去掉outer join。 5)考虑组合索引或覆盖索引消除clustered index scan。 上面1和2点建议立即消除了worktable,性能提高了几倍以上,效果非常明显。 1)限制结果集 要尽量减少返回的结果行,包括行数和字段列数。 返回的结果越大,意味着相应的SQL语句的logical reads 就越大,对服务器的性能影响就越甚。 一个很不好的设计就是返回表的所有数据: Select * from tablename 即使表很小也会导致并发问题。更坏的情况是,如果表有上百万行的话,那后果将是灾难性的。 它不但可能带来极重的磁盘IO,更有可能把数据库缓冲区中的其他缓存数据挤出,使得这些数据下次必须再从磁盘读取。 必须设计良好的SQL语句,使得其有where语句或TOP语句来限制结果集大小。 2)合理的表设计 SQL Server 2005将支持表分区技术。利用表分区技术可以实现数据表的流动窗口功能。 在流动窗口中可以轻易的把历史数据移出,把新的数据加入,从而使表的大小基本保持稳定。 另外,表的设计未必需要非常范式化。有一定的字段冗余可以增加SQL语句的效率,减少JOIN的数目,提高语句的执行速度。 3)OLAP和OLTP模块要分开 OLAP和OLTP类型的语句是截然不同的。前者往往需要扫描整个表做统计分析,索引对这样的语句几乎没有多少用处。 索引只能够加快那些如sum,group by之类的聚合运算。因为这个原因,几乎很难对OLAP类型的SQL语句进行优化。 而OLTP语句则只需要访问表的很小一部分数据,而且这些数据往往可以从内存缓存中得到。 为了避免OLAP 和OLTP语句相互影响,这两类模块需要分开运行在不同服务器上。 因为OLAP语句几乎都是读取数据,没有更新和写入操作,所以一个好的经验是配置一台standby 服务器,然后OLAP只访问standby服务器。 4)使用存储过程 可以考虑使用存储过程封装那些复杂的SQL语句或商业逻辑,这样做有几个好处。 一是存储过程的执行计划可以被缓存在内存中较长时间,减少了重新编译的时间。 二是存储过程减少了客户端和服务器的繁复交互。 三是如果程序发布后需要做某些改变你可以直接修改存储过程而不用修改程序,避免需要重新安装部署程序。 索引优化 很多数据库系统性能不理想是因为系统没有经过整体优化,存在大量性能低下的SQL 语句。 这类SQL语句性能不好的首要原因是缺乏高效的索引。 没有索引除了导致语句本身运行速度慢外,更是导致大量的磁盘读写操作,使得整个系统性能都受之影响而变差。 解决这类系统的首要办法是优化这些没有索引或索引不够好的SQL语句。 创建索引的关键 优化SQL语句的关键是尽可能减少语句的logical reads。 这里说的logical reads是指语句执行时需要访问的单位为8K的数据页总数。 logical reads 越少,其需要的内存和CPU时间也就越少,语句执行速度就越快。 不言而喻,索引的最大好处是它可以极大减少SQL语句的logical reads数目,从而极大减少语句的执行时间。 创建索引的关键是索引要能够大大减少语句的logical reads。一个索引好不好,主要看它减少的logical reads多不多。 运行set statistics io命令可以得到SQL语句的logical reads信息。 set statistics io on select au_id,au_lname ,au_fname from pubs..authors where au_lname =’Green’ …

近期因工作需要,希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项,在网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现,有很多似是而非或者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息,只好自己根据以前的经验和测试结果进行总结了。