;大约140000条数据) 竟然运行了一个小时还没有完成
下面是我的几点解决方案
我的update 语句 是从一个临时表更新值到另一个正式表
因为具体数据需要保密,我就不截图了 只说说大体思路,与方法
1.查看语句是否有问题
复制俩个一模一样的表 和数据 手动执行语句 发现不到一分钟就运行成功了 这样就可以确认语句没有问题
2.查找影响updata的因素
我的第一反应是不是有锁 有锁的情况会导致等待或者死锁
查询锁
select w1.pid as 等待进程, w1.mode as 等待锁模式, w2.usename as 等待用户, w2.query as 等待会话, b1.pid as 锁的进程, b1.mode 锁的锁模式, b2.usename as 锁的用户, b2.query as 锁的会话, b2.application_name 锁的应用, b2.client_addr 锁的IP地址, b2.query_start 锁的语句执行时间 from pg_locks w1 join pg_stat_activity w2 on w1.pid=w2.pid join pg_locks b1 on w1.transactionid=b1.transactionid and w1.pid!=b1.pid join pg_stat_activity b2 on b1.pid=b2.pid where not w1.granted;
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid='62560'
查询到有锁 把锁进程杀掉 重启服务 继续跟踪 发现5分钟后 又出现锁了 反复试了几次发现跟锁没有关系
3.查询参数
首先看的的 是shared_buffers 参数,发现也没有问题
4.收缩表 VACUUM
查询数据进程时,发现自动收缩 也执行10分钟还没好 就查询表收缩的情况
用于服务器监控,可查询进程,时间消耗与锁相关
SELECT C.relname 对象名称, l.locktype 可锁对象的类型, l.pid 进程id, l.MODE 持有的锁模式, l.GRANTED 是否已经对锁进行授权, l.fastpath, psa.datname 数据库名称, psa.usesysid 用户id, psa.usename 用户名称, psa.application_name 应用程序名称, psa.client_addr 连接的IP地址, psa.client_port 连接使用的TCP端口号, psa.backend_start 进程开始时间, psa.xact_start 事务开始时间, psa.query_start 事务执行此语句时间, psa.state_change 事务状态改变时间, psa.wait_event_type 等待事件类型, psa.wait_event 等待事件, psa.STATE 查询状态, backend_xid 事务是否有写入操作, backend_xmin 是否执事务快照, psa.query 执行语句, now( ) - query_start 持续时间 FROM pg_locks l INNER JOIN pg_stat_activity psa ON ( psa.pid = l.pid ) LEFT OUTER JOIN pg_class C ON ( l.relation = C.oid ) -- where l.relation = 'tb_base_apparatus'::regclass where relkind ='r' ORDER BY query_start asc
查询是否到达自动清理的表
SELECT c.relname 表名, (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples AS 自动分析阈值, (current_setting('autovacuum_vacuum_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_vacuum_scale_factor')::NUMERIC(12,4))*reltuples AS 自动清理阈值, reltuples::DECIMAL(19,0) 活元组数, n_dead_tup::DECIMAL(19,0) 死元组数 FROM pg_class c LEFT JOIN pg_stat_all_tables d ON C.relname = d.relname WHERE c.relname LIKE'tb%' AND reltuples > 0 AND n_dead_tup > (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples;
然后发现死元祖太多
然后我手动收缩了这个表 之后更新的就快了
VACUUM FULL VERBOSE 表名; VACUUM FULL VERBOSE ANALYZE 表名;
5.总结
遇到这种情况 先需求确保你的sql语句没有问题,然后查看有没有锁 可以EXPLAIN 一下 ,看看数据库参数,是不是数据库的性能原因 最后再看看是不是需要收缩表
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
暂无评论...
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
2024年11月23日
2024年11月23日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]