- 浏览: 3432147 次
- 性别:
- 来自: 珠海
文章分类
- 全部博客 (1633)
- Java (250)
- Android&HTML5 (111)
- Struts (10)
- Spring (236)
- Hibernate&MyBatis (115)
- SSH (49)
- jQuery插件收集 (55)
- Javascript (145)
- PHP (77)
- REST&WebService (18)
- BIRT (27)
- .NET (7)
- Database (105)
- 设计模式 (16)
- 自动化和测试 (19)
- Maven&Ant (43)
- 工作流 (36)
- 开源应用 (156)
- 其他 (16)
- 前台&美工 (119)
- 工作积累 (0)
- OS&Docker (83)
- Python&爬虫 (28)
- 工具软件 (157)
- 问题收集 (61)
- OFbiz (6)
- noSQL (12)
最新评论
-
HEZR曾嶸:
你好博主,这个不是很理解,能解释一下嘛//左边+1,上边+1, ...
java 两字符串相似度计算算法 -
天使建站:
写得不错,可以看这里,和这里的这篇文章一起看,有 ...
jquery 遍历对象、数组、集合 -
xue88ming:
很有用,谢谢
@PathVariable映射出现错误: Name for argument type -
jnjeC:
厉害,困扰了我很久
MyBatis排序时使用order by 动态参数时需要注意,用$而不是# -
TopLongMan:
非常好,很实用啊。。
PostgreSQL递归查询实现树状结构查询
http://database.51cto.com/art/200904/118526.htm
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用.
解决办法:
其实只需要对该脚本略做改进,查询速度便会提高近百倍。改进方法如下:
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个临时表里头,然后再用临时表去做复杂关联
2.索引问题
在做性能跟踪分析过程中,经常发现有不少后台程序的性能问题是因为缺少合适索引造成的,有些表甚至一个索引都没有。这种情况往往都是因为在设计表时,没去定义索引,而开发初期,由于表记录很少,索引创建与否,可能对性能没啥影响,开发人员因此也未多加重视。然一旦程序发布到生产环境,随着时间的推移,表记录越来越多
这时缺少索引,对性能的影响便会越来越大了。
这个问题需要数据库设计人员和开发人员共同关注
法则:不要在建立的索引的数据列上进行下列操作:
◆避免对索引字段进行计算操作
◆避免在索引字段上使用not,<>,!=
◆避免在索引列上使用IS NULL和IS NOT NULL
◆避免在索引列上出现数据类型转换
◆避免在索引字段上使用函数
◆避免建立索引的列中使用空值。
3.复杂操作
部分UPDATE、SELECT 语句 写得很复杂(经常嵌套多级子查询)——可以考虑适当拆成几步,先生成一些临时数据表,再进行关联操作
4.update
同一个表的修改在一个过程里出现好几十次,如:
update table1
set col1=...
where col2=...;
update table1
set col1=...
where col2=...
......
象这类脚本其实可以很简单就整合在一个UPDATE语句来完成(前些时候在协助xxx项目做性能问题分析时就发现存在这种情况)
5.在可以使用UNION ALL的语句里,使用了UNION
UNION 因为会将各查询子集的记录做比较,故比起UNION ALL ,通常速度都会慢上许多。一般来说,如果使用UNION ALL能满足要求的话,务必使用UNION ALL。还有一种情况大家可能会忽略掉,就是虽然要求几个子集的并集需要过滤掉重复记录,但由于脚本的特殊性,不可能存在重复记录,这时便应该使用UNION ALL,如xx模块的某个查询程序就曾经存在这种情况,见,由于语句的特殊性,在这个脚本中几个子集的记录绝对不可能重复,故可以改用UNION ALL)
6.在WHERE 语句中,尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道,但仍有不少人这么使用,我想其中一个最主要的原因可能是为了编写写简单而损害了性能,那就不可取了
9月份在对XX系统做性能分析时发现,有大量的后台程序存在类似用法,如:
......
where trunc(create_date)=trunc(:date1)
虽然已对create_date 字段建了索引,但由于加了TRUNC,使得索引无法用上。此处正确的写法应该是
where create_date>=trunc(:date1) and create_date
或者是
where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)
注意:因between 的范围是个闭区间(greater than or equal to low value and less than or equal to high value.),
故严格意义上应该再减去一个趋于0的小数,这里暂且设置成减去1秒(1/(24*60*60)),如果不要求这么精确的话,可以略掉这步。
7.对Where 语句的法则
7.1 避免在WHERE子句中使用in,not in,or 或者having。
可以使用 exist 和not exist代替 in和not in。
可以使用表链接代替 exist。Having可以用where代替,如果无法代替可以分两步处理。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)
优化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)
7.2 不要以字符格式声明数字,要以数字格式声明字符值。(日期同样)否则会使索引无效,产生全表扫描。
例子使用:
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
不要使用:SELECT emp.ename, emp.job FROM emp WHERE emp.empno = ‘7369’
8.对Select语句的法则
在应用程序、包和过程中限制使用select * from table这种方式。看下面例子
使用SELECT empno,ename,category FROM emp WHERE empno = '7369‘
而不要使用SELECT * FROM emp WHERE empno = '7369'
9. 排序
避免使用耗费资源的操作,带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行,耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序
10.临时表
慎重使用临时表可以极大的提高系统性能
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用.
解决办法:
其实只需要对该脚本略做改进,查询速度便会提高近百倍。改进方法如下:
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个临时表里头,然后再用临时表去做复杂关联
2.索引问题
在做性能跟踪分析过程中,经常发现有不少后台程序的性能问题是因为缺少合适索引造成的,有些表甚至一个索引都没有。这种情况往往都是因为在设计表时,没去定义索引,而开发初期,由于表记录很少,索引创建与否,可能对性能没啥影响,开发人员因此也未多加重视。然一旦程序发布到生产环境,随着时间的推移,表记录越来越多
这时缺少索引,对性能的影响便会越来越大了。
这个问题需要数据库设计人员和开发人员共同关注
法则:不要在建立的索引的数据列上进行下列操作:
◆避免对索引字段进行计算操作
◆避免在索引字段上使用not,<>,!=
◆避免在索引列上使用IS NULL和IS NOT NULL
◆避免在索引列上出现数据类型转换
◆避免在索引字段上使用函数
◆避免建立索引的列中使用空值。
3.复杂操作
部分UPDATE、SELECT 语句 写得很复杂(经常嵌套多级子查询)——可以考虑适当拆成几步,先生成一些临时数据表,再进行关联操作
4.update
同一个表的修改在一个过程里出现好几十次,如:
update table1
set col1=...
where col2=...;
update table1
set col1=...
where col2=...
......
象这类脚本其实可以很简单就整合在一个UPDATE语句来完成(前些时候在协助xxx项目做性能问题分析时就发现存在这种情况)
5.在可以使用UNION ALL的语句里,使用了UNION
UNION 因为会将各查询子集的记录做比较,故比起UNION ALL ,通常速度都会慢上许多。一般来说,如果使用UNION ALL能满足要求的话,务必使用UNION ALL。还有一种情况大家可能会忽略掉,就是虽然要求几个子集的并集需要过滤掉重复记录,但由于脚本的特殊性,不可能存在重复记录,这时便应该使用UNION ALL,如xx模块的某个查询程序就曾经存在这种情况,见,由于语句的特殊性,在这个脚本中几个子集的记录绝对不可能重复,故可以改用UNION ALL)
6.在WHERE 语句中,尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道,但仍有不少人这么使用,我想其中一个最主要的原因可能是为了编写写简单而损害了性能,那就不可取了
9月份在对XX系统做性能分析时发现,有大量的后台程序存在类似用法,如:
......
where trunc(create_date)=trunc(:date1)
虽然已对create_date 字段建了索引,但由于加了TRUNC,使得索引无法用上。此处正确的写法应该是
where create_date>=trunc(:date1) and create_date
或者是
where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)
注意:因between 的范围是个闭区间(greater than or equal to low value and less than or equal to high value.),
故严格意义上应该再减去一个趋于0的小数,这里暂且设置成减去1秒(1/(24*60*60)),如果不要求这么精确的话,可以略掉这步。
7.对Where 语句的法则
7.1 避免在WHERE子句中使用in,not in,or 或者having。
可以使用 exist 和not exist代替 in和not in。
可以使用表链接代替 exist。Having可以用where代替,如果无法代替可以分两步处理。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)
优化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)
7.2 不要以字符格式声明数字,要以数字格式声明字符值。(日期同样)否则会使索引无效,产生全表扫描。
例子使用:
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
不要使用:SELECT emp.ename, emp.job FROM emp WHERE emp.empno = ‘7369’
8.对Select语句的法则
在应用程序、包和过程中限制使用select * from table这种方式。看下面例子
使用SELECT empno,ename,category FROM emp WHERE empno = '7369‘
而不要使用SELECT * FROM emp WHERE empno = '7369'
9. 排序
避免使用耗费资源的操作,带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行,耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序
10.临时表
慎重使用临时表可以极大的提高系统性能
发表评论
-
全局唯一ID设计方案
2016-06-28 09:42 1226在分布式系统中,经常需要使用全局唯一ID查找对应的数据。产生这 ... -
MYSQL中取当前周/月/季/年的第一天与最后一天
2016-06-27 17:34 3006http://my.oschina.net/zx0211/bl ... -
按周,按月,按日,按小时分组统计数据
2016-06-27 17:07 3282http://my.oschina.net/mjRao/blo ... -
SELECT INTO 和 INSERT INTO SELECT 两种表复制语句区别
2016-06-27 16:27 1023http://my.oschina.net/MiniBu/bl ... -
CitusDB logo基于 PostgreSQL 的集群数据库 CitusDB
2016-06-20 11:43 1089http://www.oschina.net/p/citusd ... -
MYSQL级联查询,包括向上向下的级联
2016-05-31 11:47 2246http://my.oschina.net/u/178116/ ... -
阿里巴巴Druid数据源的配置与使用
2016-05-24 17:42 1551http://my.oschina.net/wjme/blog ... -
MySQL全文索引
2016-05-11 17:21 995MySQL全文索引Match Against与Like比较 h ... -
mysql中间件研究(Atlas,cobar,TDDL), 分库分表插件
2016-05-09 14:15 3458http://www.guokr.com/blog/47576 ... -
Druid使用起步—在javaWeb项目中配置监控
2016-05-06 11:41 3277Druid使用起步—在javaWeb项目中配置监控: http ... -
基于spring,Atomikos,mybatis的分布式动态数据源JTA实现
2016-04-27 16:37 1083原文;http://www.blogjava.net/zuxi ... -
用Haproxy来做PostgreSQL的负载均衡
2016-04-22 09:48 1608http://my.oschina.net/Kenyon/bl ... -
MySQL的root密码重置
2016-04-14 10:29 970http://my.oschina.net/shawnplay ... -
分布式事务管理
2016-03-31 16:43 1044http://my.oschina.net/pingpangk ... -
基于 PostgreSQL 的集群数据库 CitusDB
2016-03-25 10:24 2456http://www.oschina.net/p/citusd ... -
shell中读写mysql数据库
2016-03-13 15:32 1407http://mingxinglai.com/cn/2013/ ... -
PostgreSQL In BigData 大数据Postgresql
2016-03-10 10:00 19781.BigSQL (整合了pg和hadoop的一个开源项目) ... -
MySQL管理客户端 Adminer
2016-02-14 10:31 1558http://www.oschina.net/p/admine ... -
PostgreSQ 表的继承和分区
2016-01-08 15:02 1192PostgreSQL分区表(Table Partitionin ... -
利用系统缓存提高PostgreSQL操作效率
2015-12-17 09:01 1209http://my.oschina.net/Suregogo/ ...
相关推荐
Oracle数据库的性能优化直接关系到系统的运行效率,而影响数据库性能...《Oracle 高性能SQL引擎剖析:SQL优化与调优机制详解》内容丰富且深入,破解了Oracle技术的很多秘密,适合Oracle数据库管理员、应用开发人员参考。
在实际操作中,SQL优化与调优是一个不断迭代的过程,需要数据库管理员结合具体的业务场景和性能指标,综合运用上述知识点,通过测试和实践不断调整和优化。由于是关于Oracle高性能SQL引擎的深入剖析,这本资料是...
### Oracle SQL性能优化技巧大总结 #### 一、选择最有效率的表名顺序 **背景**:在基于规则的优化器(RBO)中,Oracle解析器处理FROM子句中的表名是从右向左的。为了提高查询效率,需要合理安排表的顺序。 **技巧...
`Oracle语句优化53个规则详解 详解 规则 优化 语句 ORACLE SQL 访问 共享 相同 _中国网管联盟-网管网-bitsCN_com.htm`可能列出了53条具体的SQL优化建议,如使用绑定变量、避免在WHERE子句中使用计算表达式等。...
### Oracle SQL性能优化详解 #### 一、优化器种类及其设置 在Oracle SQL性能优化过程中,选择合适的优化器至关重要。Oracle提供了三种类型的优化器:基于规则的优化器(Rule-based Optimizer, RBO),基于成本的优化...
总的来说,Oracle索引详解及SQL优化是一个深度广度兼具的主题,需要结合实际数据库结构和业务需求,灵活应用各种索引类型和优化策略,以实现数据库性能的最大化。通过深入学习和实践,你可以更好地驾驭Oracle数据库...
【SQL语句性能测试详解】 在软件开发中,SQL语句的性能是数据库管理系统的关键因素,因为它直接影响到应用程序的响应时间和资源消耗。本篇将详细阐述如何使用LoadRunner工具来测试SQL语句或存储过程的执行性能,...
数据库性能优化是一个涵盖广泛的主题,涉及到数据库设计、查询优化、硬件配置、索引策略等多个方面。以下是一些关键的知识点: 1. **查询优化**:这是数据库性能优化的核心部分。通过对SQL查询语句进行分析和改写,...
### ORACLE SQL性能优化系列知识点详解 #### 一、选用合适的Oracle优化器 在Oracle数据库中,优化器的选择对于SQL语句的执行效率至关重要。Oracle提供了三种不同的优化器模式: 1. **基于规则的优化器(RULE)**...
### Oracle SQL性能优化详解 #### 一、选用适合的Oracle优化器 在Oracle数据库中,SQL语句的执行效率很大程度上取决于所选的优化器。优化器负责决定SQL语句的执行计划,即如何最有效地从数据库中检索数据。Oracle...
Oracle高性能SQL引擎剖析:SQL优化与调优机制详解
### 大数据 SQL 性能优化与分页算法详解 #### 一、引言 在当前信息化社会背景下,数据量的急剧增长使得大数据处理成为一项关键任务。在处理大规模数据集时,SQL 查询的性能优化变得尤为重要。本文将详细介绍如何在...
MySQL性能优化是一个涵盖广泛的主题,涉及数据库架构设计、索引优化、SQL查询优化以及事务处理等多个方面。在本文中,我们将深入探讨其中的关键点。 首先,数据库Schema设计的优化至关重要。高效模型设计包括选择...
第2章 风驰电掣——有效缩短SQL优化过程 24 2.1 SQL调优时间都去哪儿了 25 2.1.1 不善于批处理频频忙交互 25 2.1.2 无法抓住主要矛盾瞎折腾 25 2.1.3 未能明确需求目标白费劲 26 2.1.4 没有分析操作难度乱调优...
Oracle 高性能SQL引擎剖析SQL优化与调优机制详解(黄玮).
因此,掌握SQL优化技巧对于确保数据库高效运行至关重要。 #### 常见SQL优化策略 1. **合理利用索引**:索引能够加速数据检索过程,但过多或不合理的索引也会增加磁盘空间的消耗和数据更新时的开销。因此,根据查询...