优化 postgresDB 上的 sql 查询答案

【问题标题】：Optimize sql query on postgresDB优化 postgresDB 上的 sql 查询
【发布时间】：2018-05-19 20:43:12
【问题描述】：

我的数据库中有大约 700 个表。当我运行下面的脚本时，大约需要 1 小时。如何优化此查询？

数据库：Postgres

DO $$
DECLARE
    tables_list CURSOR FOR
        select distinct t_name, t_schema from information_schema.columns 
 where column_name = 'deleted_flag' 
    and t_schema='customer' and t_name not like 'v_%';
BEGIN
    FOR t_record IN tables_list LOOP
        EXECUTE 'update ' || t_record.table_schema || '.' ||      t_record.table_name || ' set deleted_flag=false';
    END LOOP;
end;
$$;

最后，此架构中的所有表都应将此字段 deleted_flag 设置为 false。我必须在生产环境中经常运行这个脚本。如果有人可以帮助如何优化此脚本，不胜感激。

你认为如果在where子句中添加一个检查，

EXECUTE 'update ' || t_record.table_schema || '.' ||      t_record.table_name || ' set deleted_flag=false where deleted_flag=true';

执行时间会更短吗？

【问题讨论】：

强烈建议不要使用字符串连接。改用FORMAT() 函数（它处理混合大小写和标识符中嵌入的空白）
你有例子吗？它适用于 postgres 吗？
stackoverflow.com/a/39204821/905902

标签： sql postgresql

【解决方案1】：

没有办法让它真正有效。

以下是您可以采取哪些措施来加快速度：

您绝对应该在查询中添加WHERE deleted_flag 以避免不必要的更新。
如果deleted_flag = true只有几行，你可以像这样创建部分索引：
```
CREATE INDEX ON atable ((1)) WHERE deleted_flag;
```
如果行数过多而无法使用部分索引，请使用fillfactor = 50 创建表并确保deleted_flag 上没有索引。

然后您就可以享受便宜得多的HOT更新了。
将max_wal_size 设置得足够高，这样您就不会遇到太多检查点。
获得足够的 RAM 以使整个数据库都适合内存。
获得快速存储。

但我认为您的设计很奇怪，最好的解决方案是找到避免这些定期更新的方法。

【讨论】：

follfactor?你的意思是fillfactor，不是吗？
我的意思是foolfactor。不，严重 - 已修复。谢谢。