PostgreSQL中vacuum 物理文件truncate发生的条件

与我联系：
微信公众号：数据库杂记   个人微信: iiihero
我是iihero. 也可以叫我Sean.
iihero@CSDN(https://blog.csdn.net/iihero) 
Sean@墨天轮 (https://www.modb.pro/u/16258)
数据库领域的资深爱好者一枚。
水木早期数据库论坛发起人 db2@smth就是俺，早期多年水木论坛数据库版版主。
国内最早一批DB2 DBA。前后对Sybase ASE及SQLAnywhere, PostgreSQL, 
HANA, Oracle, DB2, SQLite均有涉猎。曾长期担任CSDN相关数据库版版主。
SAP数据库技术专家与开发架构师，PostgreSQL ACE.
代表作有：<<Java2网络协议内幕>> <<Oracle Spatial及OCI高级编程>> 
<<Sybase ASE 15.X全程实践>>
兴趣领域：数据库技术及云计算、GenAI业余专长爱好：中国武术六段 陈式太极拳第13代传人（北京陈式太极拳第5代传人）
职业太极拳教练，兼任北京陈式太极拳研究会副秘书长。
如果想通过习练陈式太极拳强身健体，也可以与我联系。

前言

前段时间，有些同学说到vacuum截断的行为时，认为，只要末尾是空页，无论多少，都会被截断，真是这样的吗？

PostgreSQL当中，由于vacuum的操作并不总能将死元组的空间进行”物理截断”，虽然说是回收了（表示空间可重用），但是真正的物理文件的大小依然不会收缩。那么什么时候这个空间会被真正截断呢？

我们不妨看看源代码：

摘自： src/backend/access/heap/vacuumlazy.c/** Space/time tradeoff parameters: do these need to be user-tunable?** To consider truncating the relation, we want there to be at least* REL_TRUNCATE_MINIMUM or (relsize / REL_TRUNCATE_FRACTION) (whichever* is less) potentially-freeable pages.*/
#define REL_TRUNCATE_MINIMUM    1000
#define REL_TRUNCATE_FRACTION    16/** should_attempt_truncation - should we attempt to truncate the heap?** Don't even think about it unless we have a shot at releasing a goodly* number of pages.  Otherwise, the time taken isn't worth it, mainly because* an AccessExclusive lock must be replayed on any hot standby, where it can* be particularly disruptive.** Also don't attempt it if wraparound failsafe is in effect.  The entire* system might be refusing to allocate new XIDs at this point.  The system* definitely won't return to normal unless and until VACUUM actually advances* the oldest relfrozenxid -- which hasn't happened for target rel just yet.* If lazy_truncate_heap attempted to acquire an AccessExclusiveLock to* truncate the table under these circumstances, an XID exhaustion error might* make it impossible for VACUUM to fix the underlying XID exhaustion problem.* There is very little chance of truncation working out when the failsafe is* in effect in any case.  lazy_scan_prune makes the optimistic assumption* that any LP_DEAD items it encounters will always be LP_UNUSED by the time* we're called.*/
static bool
should_attempt_truncation(LVRelState *vacrel)
{BlockNumber possibly_freeable;if (!vacrel->do_rel_truncate || VacuumFailsafeActive)return false;possibly_freeable = vacrel->rel_pages - vacrel->nonempty_pages;if (possibly_freeable > 0 &&(possibly_freeable >= REL_TRUNCATE_MINIMUM ||possibly_freeable >= vacrel->rel_pages / REL_TRUNCATE_FRACTION))return true;return false;
}

从代码里头可以看出，只有不少于1000个空页或者空页比例不低于总页数/16的情况下，才会真正发生truncate。两者必须满足其中之一。

这方面的原理分析，在cc老师的文章里都有谈及 （https://mp.weixin.qq.com/s/ymFYOAGin2kqo96gfNYDnQ），为加深印象，我们可以通过实验来进一步验证。

实验验证

-- 安装几个内置的插件：
create extension pg_buffercache;
create extension pg_freespacemap;
create extension pageinspect;
create extension pg_visibility;
create extension pgstattuple

准备表及数据

CREATE OR REPLACE FUNCTION random_string( int ) RETURNS TEXT as $$
SELECT string_agg(substring('abcdefghijklmnopqrstuvwxyz', round(random() * 25 + 0.5)::integer, 1), '') FROM generate_series(1, $1); 
$$ language sql;postgres=# create table t(id int primary key, col2 varchar(4000));
CREATE TABLE
postgres=# insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
INSERT 0 4000

相当于是建一个表t, 往里边插入4000条数据。里边使用随机串，主要是为了避免字符串压缩。我们看看相关表大小。

select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8331264 | 8224768 |  106496 | 8331264 |  8192000 | 32768
(1 row)

我们看到，上边的空间大小主要集中在表本身。因为实际插入长度2000左右，还不会进入到Toast空间。

postgres=# select min(blkno), max(blkno) from pg_freespace('t');min | max
-----+-----0 | 999
(1 row)postgres=# select pg_relpages('t');pg_relpages
-------------1000
(1 row)postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 4000
tuple_len          | 8128000
tuple_percent      | 99.22
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 20000
free_percent       | 0.24

可以看出，这个表实际占用了1000个页面（每4条记录占用一页，符合预期）。

删除末尾的4条记录

我们就只删除末尾的4条记录，看下情况，相当于是最后一页。

postgres=# delete from t where id >= 3997;
DELETE 4
postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 3996
tuple_len          | 8119872
tuple_percent      | 99.12
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 28128
free_percent       | 0.34postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 1 pages from table (0.10% of total) have 4 dead item identifiers
INFO:  table "t": found 0 removable, 0 nonremovable row versions in 1 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223185
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29708"
INFO:  table "pg_toast_29708": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223186
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 3996
tuple_len          | 8119872
tuple_percent      | 99.12
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 28128
free_percent       | 0.34

上边的信息也可以看到，并没有什么截断发生。统计一下物理空间：

select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8339456 | 8232960 |  106496 | 8339456 |  8192000 | 40960
(1 row)

表的物理大小，仍然为：8192000

postgres=# select pg_relation_filepath('t');pg_relation_filepath
----------------------base/13236/29708\! stat postgres/data/base/13236/29708
16777234 104752459 -rw------- 1 ***** ***** 0 8192000 "Feb  4 06:40:12 2024" "Feb  4 06:44:03 2024" "Feb  4 06:44:03 2024" "Feb  4 06:40:12 2024" 4096 16512 0 postgres/data/base/13236/29708

继续删除12条记录：

postgres=# delete from t where id >= 4000 - 16 + 1;
DELETE 12

INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 4 pages from table (0.40% of total) have 16 dead item identifiers
INFO:  table "t": found 16 removable, 3984 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223205
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29729"
INFO:  table "pg_toast_29729": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223205
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8339456 | 8232960 |  106496 | 8339456 |  8192000 | 40960
(1 row)

累计16个页面:

postgres=# delete from t where id >= 4000 - 64 + 1;
DELETE 32
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 16 pages from table (1.60% of total) have 64 dead item identifiers
INFO:  table "t": found 32 removable, 0 nonremovable row versions in 16 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223209
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29729"
INFO:  table "pg_toast_29729": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223210
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

还是一点动静都没有。

那么要多少个空页，才有效：1000/16 = 62页？　

我们不妨逐步推进这个实验，累计16一直往上，看到底多少次以后，开始有截断？

。。。。。。

发现，删除80条记录（20个页面），结果不变

删除84条记录时，结果仍不变。

删除88条记录的时候（22个页面），这个时候会截断20个页面。（INFO:  table "t": truncated 1000 to 980 pages）

postgres=# delete from t where id >= 4000 - 88 + 1;
DELETE 8
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 2 pages from table (0.20% of total) have 8 dead item identifiers
INFO:  table "t": found 8 removable, 0 nonremovable row versions in 22 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223218
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 980 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29736"
INFO:  table "pg_toast_29736": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223219
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpostgres=# select pg_relpages('t');pg_relpages
-------------980
(1 row)

事实上，我们发现，在删除87条记录的时候，仍然不会发生截断：

postgres=# delete from t where id >= 4000 - 87+1; vacuum verbose t;
DELETE 1
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 1 pages from table (0.10% of total) have 3 dead item identifiers
INFO:  table "t": found 1 removable, 1 nonremovable row versions in 22 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223228
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29743"
INFO:  table "pg_toast_29743": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223228
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

autovacuum禁掉，去除影响

我们禁掉autovacuum, 并进行连续操作

drop table t;create table t(id int, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;postgres=# insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 88+1; vacuum verbose t;
DELETE 88
INFO:  vacuuming "public.t"
INFO:  table "t": removed 88 dead item identifiers in 22 pages
INFO:  table "t": found 88 removable, 3912 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223240
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29756"
INFO:  table "pg_toast_29756": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223240
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select pg_relpages('t');pg_relpages
-------------1000
(1 row)

如果我们快速进行处理：

postgres=# drop table t;create table t(id int, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
DROP TABLE
CREATE TABLE
ALTER TABLE
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 247+1; vacuum verbose t; select pg_relpages('t');
DELETE 247
INFO:  vacuuming "public.t"
INFO:  table "t": removed 247 dead item identifiers in 62 pages
INFO:  table "t": found 247 removable, 3753 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29776"
INFO:  table "pg_toast_29776": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------1000
(1 row)-- 再执行一次
postgres=# delete from t where id >= 4000 - 247+1; vacuum verbose t; select pg_relpages('t');
DELETE 0
INFO:  vacuuming "public.t"
INFO:  table "t": found 0 removable, 0 nonremovable row versions in 1 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 60 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 939 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29776"
INFO:  table "pg_toast_29776": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223268
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------939
(1 row)

这里会因为:  Skipped 0 pages due to buffer pins, 60 frozen pages.,  最后还是触发truncate. 但是从实验结果来看，在没有到达62个页面之前，第一次插，确实没有被trunate.

删除62个页面对应的记录：

postgres=# drop table t;create table t(id int primary key, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
DROP TABLE
CREATE TABLE
ALTER TABLE
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 248+1; vacuum verbose t; select pg_relpages('t');
DELETE 248
INFO:  vacuuming "public.t"
INFO:  scanned index "t_pkey" to remove 248 row versions
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  table "t": removed 248 dead item identifiers in 62 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  index "t_pkey" now contains 3752 row versions in 13 pages
DETAIL:  248 index row versions were removed.
0 index pages were newly deleted.
0 index pages are currently deleted, of which 0 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": found 248 removable, 3752 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223284
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 938 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29795"
INFO:  table "pg_toast_29795": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223285
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------938postgres=# select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------7831552 | 7725056 |  106496 | 7831552 |  7684096 | 40960
(1 row)         

小结

vacuum一个表，产生物理截断，默认情况下，需要空页达到一定条件。上边的实验表明，在空页没达到1000个页同时也没达到总页数/16的情况下，第一次尝试截断，并不会真正发生。（autovacuum关闭，是为了屏蔽自动vacuum的影响）因为autovacuum还会触发freeze等其它动作，会间接产生影响。

上边的实验，禁掉auto vacuum, 在删除最后62个页面的情况下，会发生截断。

如果不禁掉auto vacuum， 你会发现在20个页面被删除的情况下，会发生截断，那刚好是autovacuum默认触发的条件（20%）。而它本身又会触发与freeze action相关的操作，最终会引发截断。

一个小实验，结合代码，可以引发很多思考。希望这个实验对vacuum原理感兴趣的人有所帮助。

与我联系：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/548763.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

特约撰稿 | 李杰：2024快消品牌企业如何赢在数字化？

特约撰稿 | 李杰：2024快消品牌企业如何赢在数字化？

随着用户群体、消费场景的细分&#xff0c;以及渠道的进一步多元化&#xff0c;让快消品企业遇到了一些机遇与挑战&#xff0c;在这样的大趋势之下&#xff0c;2024年快消品牌企业&#xff0c;要脱颖而出赢得增长&#xff0c;必须要把握战略上的机会。 作者&#xff5c;纷享销…
阅读更多...
苍穹外卖-day09：用户端历史订单模块（理解业务逻辑），商家端订单管理模块（理解业务逻辑），校验收货地址是否超出配送范围（相关API）

苍穹外卖-day09：用户端历史订单模块（理解业务逻辑），商家端订单管理模块（理解业务逻辑），校验收货地址是否超出配送范围（相关API）

用户端历史订单模块 1. 查询历史订单&#xff08;分页查询&#xff09; 1.1 需求分析和设计 产品原型&#xff1a; 业务规则 分页查询历史订单可以根据订单状态查询展示订单数据时&#xff0c;需要展示的数据包括&#xff1a;下单时间、订单状态、订单金额、订单明细&#…
阅读更多...
探寻源码宝藏：介绍开源项目“source-code-hunter“

探寻源码宝藏：介绍开源项目“source-code-hunter“

最近处于金三银四的面试黄金期&#xff0c;许多同学在面试中反映现在要求非常高&#xff0c;阅读源码几乎是必问项。然而&#xff0c;阅读源码时常常觉得晦涩难懂&#xff0c;令人头疼。今天在浏览 GitHub 时&#xff0c;我发现了一个名为 source-code-hunter 的宝藏项目。这个…
阅读更多...
苍穹外卖-day06：HttpClient、微信小程序开发、微信登录（业务流程）、导入商品浏览功能代码（业务逻辑）

苍穹外卖-day06：HttpClient、微信小程序开发、微信登录（业务流程）、导入商品浏览功能代码（业务逻辑）

苍穹外卖-day06 课程内容 HttpClient微信小程序开发微信登录导入商品浏览功能代码 功能实现&#xff1a;微信登录、商品浏览 微信登录效果图&#xff1a; 商品浏览效果图&#xff1a; 1. HttpClient 1.1 介绍 HttpClient 是Apache Jakarta Common 下的子项目&#xff0c;…
阅读更多...
在Linux系统中如何查询日志？

在Linux系统中如何查询日志？

在工作中&#xff0c;我们有时候会定位问题&#xff0c;这时候就需要查询日志了&#xff0c;那么查询日志的命令有哪些呢&#xff1f; cat 查看某个日志文件中的所有内容。 使用示例&#xff1a;cat file.txt 显示 file.txt 文件的所有内容。 如果要对查询的结果进行筛选&am…
阅读更多...
代码随想录算法训练营第11天| 20. 有效的括号，1047. 删除字符串中的所有相邻重复项，150. 逆波兰表达式求值

代码随想录算法训练营第11天| 20. 有效的括号，1047. 删除字符串中的所有相邻重复项，150. 逆波兰表达式求值

系列文章目录 目录 系列文章目录20. 有效的括号利用栈对称匹配将栈中元素弹出与判断栈顶元素是否匹配分开&#xff0c;比较耗时&#xff08;2ms)&#xff1a;若将栈中元素弹出与判断栈顶元素是否匹配放一起&#xff0c;比较节省时间(1ms)&#xff1a; 1047. 删除字符串中的所有…
阅读更多...
26双体系Java学习之字符串和其他类型相互转换

26双体系Java学习之字符串和其他类型相互转换

字符串和其他类型相互转换
阅读更多...
解决：visio导出公式为pdf图片乱码问题

解决：visio导出公式为pdf图片乱码问题

今天需要将Visio编辑好的以后的图输出pdf&#xff0c;但是点击保存后公式部分一直乱码&#xff0c;如下图所示 保存为pdf后会变成&#xff1a; 解决方案&#xff1a;保存时点击文件下方的快速打印&#xff0c;存到桌面&#xff0c;不要直接点击保存
阅读更多...
苍穹外卖-day10：Spring Task、订单状态定时处理、来单提醒（WebSocket的应用）、客户催单（WebSocket的应用）

苍穹外卖-day10：Spring Task、订单状态定时处理、来单提醒（WebSocket的应用）、客户催单（WebSocket的应用）

苍穹外卖-day10 课程内容 Spring Task订单状态定时处理WebSocket来单提醒客户催单 功能实现&#xff1a;订单状态定时处理、来单提醒和客户催单 订单状态定时处理&#xff1a; 来单提醒&#xff1a; 客户催单&#xff1a; 1. Spring Task 1.1 介绍 Spring Task 是Spring框…
阅读更多...
Python AI 之PhotoMaker 安装总结

Python AI 之PhotoMaker 安装总结

PhotoMaker 官方文档 PhotoMaker GitHub 地址:https://github.com/TencentARC/PhotoMaker PhotoMaker Windows 安装 温馨提示&#xff1a;PhotoMaker 官网github 版本为通用版本&#xff0c;如果是Windows系统安装PhotoMarker 需要使用截图下的版本&#xff1a; 第一步&am…
阅读更多...
WEB三大组件之Filter

WEB三大组件之Filter

在很多项目中通常需要用到filter来实现用户身份识别&#xff0c;并将识别出来的用户信息&#xff0c;保存到ThreadLocal对应的上下文&#xff0c;这样在后续的请求链路中&#xff0c;在任何地方都可以直接获取当前的登录用户了。 来看一下Java WEB三大组件之一的过滤器Filter&…
阅读更多...
云原生（三）、Docker网络

云原生（三）、Docker网络

Docker网络 在 Docker 中&#xff0c;不同容器之间的网络访问原理取决于容器所使用的网络模式。下面是 Docker 中常见的两种网络模式下容器间网络访问的原理&#xff1a; 桥接模式&#xff08;Bridge&#xff09;&#xff1a; 在桥接模式下&#xff0c;Docker 使用 Linux 桥接…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023