PostgreSQL 同样的语句 一会快 一会慢到底怎么回事，

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2340人左右 1 + 2 + 3 + 4 +5+6 + 7） （1 2 3 4 5 均没有空位了，请不要在问了谢谢）

最近写技术的东西的确有点少了，尤其PostgreSQL. 报应不爽，开发部的一个开发给我提了一个问题，他问我PostgreSQL 为什么不稳定，一会快一会慢。

我回答，这不可能，不会一会快，一会慢! 不是数据库的问题，应该是操作上有什么问题导致的。

了解问题中，具体的问题描述是，在PG13数据库中，定义了一个函数，在函数里面有一个对表的操作，操作的类型是UPDATE，同样的语句，在函数中运行就速度非常的慢大约需要1秒左右，但如果将语句拿出到外部，基本在100毫秒内就完成了操作。

这里需要解释一下dtCreate是变量，是从函数外部传递进来的变量。

这里外面一一排查问题

1 传递进来的值是一个固定值，在执行中变量被替换成一个固定日期，计算式的左边也是一个系统变量和传递变量后进行计算后的值，左右都是变量。

2 函数传递进来的值的类型一定要与左侧计算公式结果的类型相同，否则就产生隐士转换的问题

解决这类问题方案 1

在函数中将要执行的语句进行变量赋值，通过变量赋值中添加 explain来查看具体在函数中，语句执行的具体执行计划。如下方式

CREATE OR REPLACE FUNCTION my_function(var_value INT)
RETURNS void AS
$$
DECLARE
    query_text TEXT;
BEGIN
    -- 构建带参数的查询语句，使用 $1 作为参数占位符
    query_text := 'EXPLAIN SELECT * FROM your_table WHERE column = $1 AND column2 > $2';
    
    -- 查看执行计划
    EXECUTE query_text USING var_value, var_value * 2;
    
END;
$$
LANGUAGE plpgsql;

对比实际的不传递变量的语句执行的方式与上述的方式执行语句的执行计划是否一致，如果明显的不一致，则问题的原因就找到了。

具体类似的问题的解决方案可以通过，将执行的语句通过execute 包裹，并将变量在SQL 语句中拼接的方式来执行如。

execute 'update tablename set age = 25 where pid = '''||变量'''|| and ....'

的方式来执行语句，这样的方式在函数中执行语句，和在函数外部执行语句的方式是一致的，变量在执行语句前已经固话，是一个定值就不会产生执行计划对于值无法进行判断，而无法进行正确的执行计划的给出。

总结：1 在函数内部，尤其是使用变量时，PostgreSQL 需要在每次调用函数时重新解析和规划 SQL 语句。这会导致函数内部的 UPDATE 语句执行速度较慢

2 当使用 EXECUTE 包裹 UPDATE 语句时，PL/pgSQL 会将其视为动态 SQL，并且可以对动态 SQL 进行特定的优化和缓存，从而提高执行速度。

3 使用 EXECUTE 包裹 UPDATE 语句时，会在动态 SQL 解析过程中生成和缓存一个新的执行计划，从而加快后续执行的速度。

4 使用 EXECUTE 包裹 UPDATE 语句时，变量会在解析过程中直接绑定，从而减少了额外的开销。

更多详细的用法参见官方的信息：https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN

置顶文章：

你有发表论点的自由，我们DBA有屏蔽你封杀你的自由

PostgreSQL 14 小版本分析，有那个版本不建议使用

PostgreSQL  15 16 小版本更新信息小结 版本更新是不是挤牙膏

PostgreSQL  哪些版本尽量避免使用，版本更新重点明晰（PG12）

PostgreSQL 版本升级到PG14后，pgbouncer 无法使用怎么回事？

PostgreSQL  分组查询可以不进行全表扫描吗？速度提高上千倍？

PostgreSQL  数据压缩 LZ4  OR PGLZ 为什么都说要用新的压缩方式

往期热门文章：

SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级

MYSQL 版本迁移带来 严重生产事故“的”分析

PolarDB  Serverless POC测试中有没有坑与发现的疑问

临时工访谈：PolarDB  Serverless  发现“大”问题了  之 灭妖记 续集

临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一

PolarDB for PostgreSQL  有意思吗？有意思呀

PolarDB  Serverless POC测试中有没有坑与发现的疑问

PostgreSQL  15 16 小版本更新信息小结 版本更新是不是挤牙膏MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验

临时工访谈：从国产数据库 到 普罗大众的产品 ！与在美国创业软件公司老板对话

PostgreSQL 如何通过工具来分析PG 内存泄露

MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验

临时工访谈：我很普通，但我也有生存的权利，大龄程序员 求职贴

PostgreSQL  分组查询可以不进行全表扫描吗？速度提高上千倍？

临时工说：分析当前经济形势下 DBA 被裁员的根因

PostgreSQL PG_DUMP 工作失败了怎么回事及如何处理

MySQL 八怪（高老师）现场解决问题实录

PostgreSQL 为什么也不建议 RR隔离级别，MySQL别笑

临时工访谈：OceanBase上海开大会，我们四个开小会 OB 国产数据库破局者

临时工说：OceanBase 到访，果然数据库的世界很卷，没边

临时工访谈：恶意裁员后，一个国产数据库企业程序员的心声

临时工说：上云后给 我一个 不裁 DBA的理由

PolarDB for PostgreSQL  有意思吗？有意思呀

PostgreSQL   玩PG我们是认真的，vacuum 稳定性平台我们有了

临时工说：裁员裁到 DBA 咋办  临时工教你 套路1 2 3

PolarDB  搞那么多复杂磁盘计费的东西，抽筋了吗？

临时工说：OceanBase 到访，果然数据库的世界很卷，没边

MONGODB  ---- Austindatabases  历年文章合集

MYSQL  --Austindatabases 历年文章合集

POSTGRESQL --Austindatabaes 历年文章整理

POLARDB  -- Ausitndatabases 历年的文章集合

PostgreSQL  查询语句开发写不好是必然，不是PG的锅

SQL SERVER 如何实现UNDO REDO  和PostgreSQL 有近亲关系吗

MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量（译）

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模

MongoDB  双机热备那篇文章是  “毒”

MongoDB   会丢数据吗？在次补刀MongoDB  双机热备

临时工说：从人性的角度来分析为什么公司内MySQL 成为少数派，PolarDB 占领高处

POLARDB  到底打倒了谁  PPT 分享 （文字版）

PostgreSQL  字符集乌龙导致数据查询排序的问题，与 MySQL 稳定 "PG不稳定"

PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 （音译）

Austindatabases 公众号，主要围绕数据库技术（PostgreSQL, MySQL, Mongodb, Redis, SqlServer，PolarDB, Oceanbase 等）和职业发展，国外数据库大会音译,国外大型IT信息类网站文章翻译，等，希望能和您共同发展。

截止今天发布1189篇文章