原文:http://blog.csdn.net/hantiannan/article/details/4509231
在数据库应用开发中,速度慢的SQL比比皆是。很多速度很慢都是SQL写的不好,效率不高。比如无用的循环查询,判断,不必要的子查询,写的SQL用不上索引等等。特别是数据量很大的时候,很是头疼。我就遇到过几千万条数据的表的查询,由于子查询过多,要几个小时才执行完。显然是不符合要求的。 那该 怎么改善呢? |
|
要解决这 个速度 问题 ,我 们 首先最主要的是要找到那些SQL很慢,或者SQL中的那部分很慢。怎 样寻 找速度很慢的SQL,我 们 可以借助系 统 提供的 统计 信息功能来 查 找。 | |
1.pg_stat_user_functions :SQL文中用了存储过 程或者函数的情况,可以通 过这 个 统计 信息view来 查 看。 | |
funcid,schemaname, funcname :函数的ID | |
calls: 执 行回数 | |
total_time :函数执 行的 总 的 时间 , 单 位毫秒。 | |
self_time :不包含其他函数的执 行 时间 的自己本身的 执 行 时间 。 | |
例子: | |
=#SELECT * FROM pg_stat_user_functions; | |
funcid | schemaname | funcname | calls |total_time | self_time | |
--------+------------+----------+-------+------------+----------- | |
16434 |public | proc_1 | 4| 185| 185 | |
16738 |public | proc_2 | 5| 91| 91 | |
16741 |public | proc_3 | 2| 76| 5 | |
(3 rows) | |
从这 里面我 们 可以看到proc_3自己自身 执 行的 时间 相 对 于 总 的 时间 来 说 耗 费 的 时间 非常少,可以初步确定速度慢的函数不是proc_3。因此我就需要去 查询 其他函数的 执 行 时间 。 | |
这个机能系 统 默 认 是没有的,需要在postgresql.conf里面 设 置。默 认 是none。需要改 为 pl或者all。 | |
track_functions = pl # none, pl, all | |
2.pg_stat_statements :contrib/pg_stat_statements模块 下的机能,系 统 默 认 也是没有的。 | |
userid: 执 行SQL的用 户 | |
dbid : 数据库 ID | |
query : SQL文 | |
calls: 执 行回数 | |
total_time: 执 行 总时间 。 单 位微秒。 | |
rows: 处 理行数。返回的行数或者修改的行数。 | |
例子: | |
SELECT query, calls, total_time, rows | |
FROM pg_stat_statements ORDER BY total_time DESC LIMIT 3; | |
-[RECORD 1]------------------------------------------------------------ | |
query | UPDATE branches SET bbalance = bbalance + $1 WHERE bid = $2; | |
calls | 3000 | |
total_time | 35.9654100 | |
rows | 3000 | |
这个功能也是需要在postgresql.conf里面 设 置。 | |
shared_preload_libraries ='pg_stat_statements' | |
custom_variable_classes ='pg_stat_statements' | |
通过 上面的两种方法我 们 就可以找到那些SQL或者函数很慢, 这样 就能 够对 症下 药 了,要不然真是找不原因,很耗 费时间 。 |