Posts | 有志者事竟成

PostgreSQL Group By 不走索引？另类解决方案

Sun, 09 Nov 2025 23:50:42 +0800

PostgreSQL版本为18，MySQL版本为8.0。

PostgreSQL表现

PostgreSQL建一张表，插入1000万条数据，content字段为为107个字符串之一

create table test1(
 id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
 content varchar(100)
);
CREATE INDEX test_idx ON test1 USING btree (content);

insert into test1(content)
select REPEAT(((random() * 100000)::bigint % 107)::text, 11)
from generate_series(1, 10000000);

drop index test_idx;
create index test_idx on test1(content);

vacuum test1;
analyze test1;

执行语句如下：

set max_parallel_workers_per_gather = 0; -- 禁用并行扫描
set jit = off; -- 关闭JIT

explain analyze verbose
select content
from test1
group by content;

得到的执行计划如下，耗时2.8s：

HashAggregate (cost=229831.01..229832.08 rows=107 width=22) (actual time=2830.261..2830.270 rows=107.00 loops=1)
 Output: content
 Group Key: test1.content
 Batches: 1 Memory Usage: 32kB
 Buffers: shared hit=92331
 -> Seq Scan on test.test1 (cost=0.00..202331.01 rows=11000001 width=22) (actual time=0.014..752.663 rows=11000001.00 loops=1)
 Output: id, content
 Buffers: shared hit=92331
Planning Time: 0.093 ms
Execution Time: 2830.309 ms

强制走索引

set enable_seqscan=false; -- 禁止全表扫
set max_parallel_workers_per_gather = 0; -- 禁用并行扫描
set jit = off; -- 关闭JIT

explain analyze verbose
select content
from test1
group by content;

得到的执行计划如下，耗时1.4s：

Group (cost=0.43..209778.68 rows=107 width=22) (actual time=0.055..1434.377 rows=107.00 loops=1)
 Output: content
 Group Key: test1.content
 Buffers: shared hit=321 read=8628
 -> Index Only Scan using test_idx on test.test1 (cost=0.43..184779.50 rows=9999671 width=22) (actual time=0.054..810.491 rows=10000000.00 loops=1)
 Output: content
 Heap Fetches: 0
 Index Searches: 1
 Buffers: shared hit=321 read=8628
Planning:
 Buffers: shared hit=24
Planning Time: 0.129 ms
Execution Time: 1434.431 ms

可用看出，PostgreSQL即使强制走索引，虽然查询速度虽然有提升，但查询速度还是和表数据量有关，不能秒出结果。

MySQL表现

建表插入数据约800万条：

create table test1(
 id bigint not NULL AUTO_INCREMENT PRIMARY KEY,
 content VARCHAR(100)
);

-- 随便插入一条数据后
-- 反复执行该语句直到表里有800万条数据
INSERT into test1 (content)
select REPEAT(CONVERT(rand() * 100000 % 107, UNSIGNED INTEGER), 11) as x
from test1;

drop index test_idx on test1;
create index test_idx on test1(content);

explain analyze
select content
from test1
group by content;

有索引的情况下，耗时1ms，秒出结果：

-> Covering index skip scan for deduplication on test1 using test_idx (cost=27458 rows=18305) (actual time=0.0868..1.26 rows=108 loops=1)

没有索引的情况下，全表扫耗时5.3s：

-> Table scan on <temporary> (cost=1.66e+6..1.76e+6 rows=8.14e+6) (actual time=5395..5395 rows=108 loops=1)
 -> Temporary table with deduplication (cost=1.66e+6..1.66e+6 rows=8.14e+6) (actual time=5395..5395 rows=108 loops=1)
 -> Table scan on test1 (cost=842067 rows=8.14e+6) (actual time=0.946..2980 rows=8.39e+6 loops=1)

显然这种简单group by+有索引的场景下，MySQL的查询速度和表数据量无关，比PostgreSQL要好。

当然PostgreSQL也不是没有优点，显然其全表扫比MySQL要快很多，建索引的速度比MySQL也快(7s vs 40s)，还支持JIT和并行执行，这些都比MySQL强。

旁门左道

那么PostgreSQL到底有一些偏方来快速解决“检索某一列的唯一不同值”这个问题呢，有的。

思路打开一下：我们寄希望于Group By 能使用索引快速查询。究其原因，我们是希望不需要扫描整个索引，只扫描索引中我们需要的上层B树节点就行。

我们完全可用手动实现这个过程，先取出这一列的当前值作为最小值，然后通过递归，不断从列中取得比当前值大的最小值并替换当前值，直到取完所有值。那么当前值取过的集合，就是唯一不同值的集合。

显然，取最小值和查找比当前值大的最小值的这个过程，完全可以走索引的。我们可以用递归CTE实现这些步骤：

explain analyze verbose
WITH RECURSIVE cte AS (
 (
 SELECT content
 FROM test1
 ORDER BY 1
 LIMIT 1
 )
 UNION ALL
 SELECT l.*
 FROM cte c
 CROSS JOIN LATERAL (
 SELECT t.content
 FROM test1 t
 WHERE t.content > c.content
 ORDER BY 1
 LIMIT 1
 ) l
 )
SELECT * FROM cte;

查看执行计划，耗时不到1ms，只需0.8ms，非常完美：

CTE Scan on cte (cost=50.06..52.08 rows=101 width=218) (actual time=0.020..0.770 rows=107.00 loops=1)
 Output: cte.content
 Storage: Memory Maximum Storage: 22kB
 Buffers: shared hit=338
 CTE cte
 -> Recursive Union (cost=0.43..50.06 rows=101 width=22) (actual time=0.019..0.735 rows=107.00 loops=1)
 Storage: Memory Maximum Storage: 33kB
 Buffers: shared hit=338
 -> Limit (cost=0.43..0.45 rows=1 width=22) (actual time=0.018..0.018 rows=1.00 loops=1)
 Output: test1.content
 Buffers: shared hit=4
 -> Index Only Scan using test_idx on compub.test1 (cost=0.43..184789.84 rows=10000360 width=22) (actual time=0.017..0.017 rows=1.00 loops=1)
 Output: test1.content
 Heap Fetches: 0
 Index Searches: 1
 Buffers: shared hit=4
 -> Nested Loop (cost=0.43..4.86 rows=10 width=22) (actual time=0.006..0.006 rows=0.99 loops=107)
 Output: t.content
 Buffers: shared hit=334
 -> WorkTable Scan on cte c (cost=0.00..0.20 rows=10 width=218) (actual time=0.000..0.000 rows=1.00 loops=107)
 Output: c.content
 -> Limit (cost=0.43..0.46 rows=1 width=22) (actual time=0.006..0.006 rows=0.99 loops=107)
 Output: t.content
 Buffers: shared hit=334
 -> Index Only Scan using test_idx on compub.test1 t (cost=0.43..69931.86 rows=3333453 width=22) (actual time=0.006..0.006 rows=0.99 loops=107)
 Output: t.content
 Index Cond: (t.content > (c.content)::text)
 Heap Fetches: 0
 Index Searches: 107
 Buffers: shared hit=334
Planning Time: 0.154 ms
Execution Time: 0.798 ms

旁门左道之旁门左道

然而某些国产数据库，不支持LATERAL join，只能改写为使用相关子查询实现了：

explain analyze verbose
WITH RECURSIVE cte AS (
 -- 锚点成员：取最小的content（同原逻辑）
 (
 SELECT content
 FROM test1
 ORDER BY content -- 显式按content排序，取最小的1个
 LIMIT 1
 )
 UNION ALL
 -- 递归成员：用相关子查询找下一个值，用EXISTS控制递归终止
 SELECT (
 -- 相关子查询：为当前c.content找最小的更大值
 SELECT t.content
 FROM test1 t
 WHERE t.content > c.content -- 只找比当前值大的
 ORDER BY t.content -- 排序后取最小的
 LIMIT 1 -- 确保只返回1个值
 ) AS content
 FROM cte c -- 每一次递归都是一行当前值
 -- 过滤条件：只有存在更大值时才继续递归
 WHERE EXISTS (
 SELECT 1
 FROM test1 t
 WHERE t.content > c.content
 )
)
SELECT * FROM cte;

测试结果相差不大，耗时1.1ms：

CTE Scan on cte (cost=61.81..62.43 rows=31 width=218) (actual time=0.029..1.113 rows=107.00 loops=1)
 Output: cte.content
 Storage: Memory Maximum Storage: 22kB
 Buffers: shared hit=669
 CTE cte
 -> Recursive Union (cost=0.43..61.81 rows=31 width=218) (actual time=0.028..1.078 rows=107.00 loops=1)
 Storage: Memory Maximum Storage: 33kB
 Buffers: shared hit=669
 -> Limit (cost=0.43..0.45 rows=1 width=22) (actual time=0.027..0.027 rows=1.00 loops=1)
 Output: test1.content
 Buffers: shared hit=4
 -> Index Only Scan using test_idx on compub.test1 (cost=0.43..184789.84 rows=10000360 width=22) (actual time=0.026..0.026 rows=1.00 loops=1)
 Output: test1.content
 Heap Fetches: 0
 Index Searches: 1
 Buffers: shared hit=4
 -> Nested Loop Semi Join (cost=0.43..6.10 rows=3 width=218) (actual time=0.009..0.009 rows=0.99 loops=107)
 Output: (SubPlan 1)
 Buffers: shared hit=665
 -> WorkTable Scan on cte c (cost=0.00..0.20 rows=10 width=218) (actual time=0.000..0.000 rows=1.00 loops=107)
 Output: c.content
 -> Index Only Scan using test_idx on compub.test1 t_1 (cost=0.43..61814.26 rows=3333453 width=22) (actual time=0.005..0.005 rows=0.99 loops=107)
 Output: t_1.content
 Index Cond: (t_1.content > (c.content)::text)
 Heap Fetches: 0
 Index Searches: 107
 Buffers: shared hit=334
 SubPlan 1
 -> Limit (cost=0.43..0.46 rows=1 width=22) (actual time=0.003..0.003 rows=1.00 loops=106)
 Output: t.content
 Buffers: shared hit=331
 -> Index Only Scan using test_idx on compub.test1 t (cost=0.43..69931.86 rows=3333453 width=22) (actual time=0.003..0.003 rows=1.00 loops=106)
 Output: t.content
 Index Cond: (t.content > (c.content)::text)
 Heap Fetches: 0
 Index Searches: 106
 Buffers: shared hit=331
Planning Time: 0.177 ms
Execution Time: 1.153 ms

注意：递归CTE是有限制的，数据库也许会限制递归的深度，也许会爆栈，请仔细测试后再使用。

vacuum full性能暴跌彩蛋：

PostgreSQL中，如果对表进行vacuum full，然后强制其走索引，得到的执行计划如下：

Group (cost=0.43..600032.52 rows=107 width=22) (actual time=0.019..6437.286 rows=107.00 loops=1)
 Output: content
 Group Key: test1.content
 Buffers: shared hit=6660031
 -> Index Only Scan using test_idx on test.test1 (cost=0.43..572532.52 rows=11000001 width=22) (actual time=0.018..5664.125 rows=11000001.00 loops=1)
 Output: content
 Heap Fetches: 11000001
 Index Searches: 1
 Buffers: shared hit=6660031
Planning Time: 0.073 ms
Execution Time: 6437.376 ms

根据Kimi的解释：VACUUM FULL 后，Visibility Map 被清空，导致 Index-Only Scan 退化，必须回表查可见性，性能暴跌。

所以不要轻易使用vacuum full，平时autovacuum和vacuum就够了，如果必须 VACUUM FULL，则需要之后手动跑一次 VACUUM 来修复 VM，就能恢复查询性能了。

Proxmox VE 网卡Hang解决方法

Thu, 23 Oct 2025 07:17:24 +0800

家里的NAS安装了Proxmox VE，总是出现网卡Hang，导致NAS总是断线。

网卡为I217-V：系统日志报错信息如下：

Oct 20 00:00:07 pve kernel: e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang:
 TDH <4a>
 TDT <71>
 next_to_use <71>
 next_to_clean <49>
buffer_info[next_to_clean]:
 time_stamp <123eee4c7>
 next_to_watch <4a>
 jiffies <13e43ccc0>
 next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>

经过测试，发现关掉网卡的部分offload功能可以有效缓解该问题。

一次性执行命令（需要安装 ethtool）：

ethtool -K enp0s25 tso off gso off

开机执行：修改/etc/network/interfaces文件，在出事的网口下添加post-up命令：

iface enp0s25 inet manual
 post-up ethtool -K $IFACE tso off gso off

确认是否关闭TSO和GSO：

ethtool -k enp0s25

确认一下2项为否为off

tcp-segmentation-offload: off
generic-segmentation-offload: off

优化路由器连接参数

Thu, 09 May 2024 00:27:57 +0800

摘录了Mikrotik文档里的网络参数，并整理成Shell命令。

# mikrotik
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
echo 5 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent
echo 5 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_recv
echo 86400 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
echo 10 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_fin_wait
echo 10 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait
echo 10 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_last_ack
echo 10 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close
echo 10 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout
echo 180 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
echo 10 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
echo 10 > /proc/sys/net/netfilter/nf_conntrack_icmpv6_timeout
echo 600 > /proc/sys/net/netfilter/nf_conntrack_generic_timeout

额外再附上2条常见优化参数：

# conntrack
echo 0 > /proc/sys/net/netfilter/nf_conntrack_checksum
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal

放到路由器启动脚本里即可。

在Gist中反馈意见

Windows上使用GPG配置Git和SSH

Sat, 02 Dec 2023 22:49:58 +0800

记录一下在Windows上如何将GPG和Git，SSH结合起来使用。

环境

系统为Windows 11 23H2。

SSH是Windows系统自带的OpenSSH，不是自行安装的，也不是Git Bash里的ssh。

GPG是gnupg-w32，由scoop安装，不是Git Bash里的gpg。

SSH和GPG的版本如下：

> ssh -V
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
> gpg --version
gpg (GnuPG) 2.4.3
...
Home: C:\Users\liwenshen\scoop\apps\gpg\current\home
...

注意这里的GPG的Home文件夹，下文涉及的GPG的所有配置文件都放在这个Home文件夹中。

准备工作

GIT 配置

Git在默认情况下，使用Git Bash里自带的ssh和gpg程序。我们需要强制其使用Windows内置的SSH和gnupg-w32的gpg程序。

先在PowerShell查看当前Windows下的程序路径：

> (Get-Command ssh).Path
C:\Windows\System32\OpenSSH\ssh.exe
(Get-Command gpg).Path
C:\Users\liwenshen\scoop\apps\gpg\current\bin\gpg.exe
PS C:\Users\liwenshen>

然后根据上面的路径，指定Git使用的程序：

git config --global core.sshCommand C:\\Windows\\System32\\OpenSSH\\ssh.exe
git config --global gpg.program C:\\Users\\liwenshen\\scoop\\apps\\gpg\\current\\bin\\gpg.exe

密钥情况

查看密钥的基本情况：

> gpg -k
C:\Users\liwenshen\scoop\apps\gpg\current\home\pubring.kbx
----------------------------------------------------------
pub ed25519/82EF9F38F02BCA14 2023-06-04 [C]
 Key fingerprint = 7460 79A9 2447 E38D 1AF8 A7ED 82EF 9F38 F02B CA14
 Keygrip = 11C9D151D94FD5C4F5612CF1D79FB735E9EE08C6
uid [ultimate] liwenshen (git) <git@liwenshen.com>
sub ed25519/1B3B3B59E5427BF0 2023-06-04 [SA] [expires: 2025-06-03]
 Keygrip = E57DFA139A46760699AB482039CC3443EB0EAB22
sub cv25519/9556AA6A5BCDE6EC 2023-06-04 [E] [expires: 2025-06-03]
 Keygrip = 4DCA3FE1E8779FF9D1A6C773BD66E6CF8BE0FA63

在Git签名中，需要使用S(Signing签名)类型子密钥。在SSH连接认证中，需要使用A(Authenticating认证)类型子密钥。

可以看到，在我的情况下，一个主密钥下挂两个子密钥。其中第一个子密钥符合签名和认证的要求。因此就用这个子密钥进行SSH认证和Git签名。

这个子密钥对应的ID是1B3B3B59E5427BF0，Keygrip是E57DFA139A46760699AB482039CC3443EB0EAB22。还需要记一下主密钥的ID是82EF9F38F02BCA14，后面需要用到这3个值。

如果密钥ID和Keygrip显示不完全。可以在gpg.conf中加上下列内容后，重新执行gpg -k
keyid-format long
fingerprint
with-keygrip
或者直接执行
gpg -k --keyid-format long --fingerprint --with-keygrip

SSH 认证

GPG子密钥的SSH公钥

使用子密钥的ID，导出子密钥的SSH格式公钥，将其粘贴至Github或者服务器等SSH远程服务器上。

> gpg --export-ssh-key 1B3B3B59E5427BF0
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJXESXaFJse2EE4IJ8BVbwSoSLezT2uAHIDVz4N3mkhi openpgp:0xE5427BF0

GPG agent

GPG Agent是SSH Agent的实现，可以将SSH登录的过程中的认证环节，委托给GPG进行认证。因此想要在SSH连接中使用GPG密钥，需要先配置GPG agent。

配置GPG agent

网络上许多文章，都有用到wsl-ssh-pageant，还要书写各种的powershell启动脚本进行配置。实际上没有必要，gnupg-w32已经内置了对Windows OpenSSH的支持。只需要在gpg-agent.conf中加上下列内容就可以开启支持。

enable-ssh-support
enable-putty-support
enable-win32-openssh-support

然后将用来进行SSH认证的密钥的Keygrip写入sshcontrol文件，如：

E57DFA139A46760699AB482039CC3443EB0EAB22

警告：sshcontrol文件里新增Keygrip后务必换行，且新一行不能有空格！！！

运行GPG Agent

以下两条命令，任选一条，启动GPG agent

gpgconf --launch gpg-agent
gpg-connect-agent /bye

以下两条命令，任选一条，可以关闭GPG agent

gpgconf --kill gpg-agent
gpg-connect-agent killagent /bye

为了自动启动GPG agent，可以将GPG agent启动命令，加入计划任务中，并设置开机启动。

测试SSH

启动GPG agent后，执行命令，查询SSH能否正常使用GPG密钥。

> ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJXESXaFJse2EE4IJ8BVbwSoSLezT2uAHIDVz4N3mkhi (none)

可以看到，这个公钥和上文gpg --export-ssh-key导出的公钥是一致的，说明SSH已经可以使用GPG的子密钥了。

再测试一下SSH连接Github或者其他远程服务器，出现下列相似内容说明SSH已经认证成功。

> ssh -vT git@github.com
...
debug1: Next authentication method: publickey
debug1: Offering public key: (none) ED25519 SHA256:6aRZPwhjxDNgVIaXwaE9US9ZvUON3kzepoNH976w5vY agent
debug1: Server accepts key: (none) ED25519 SHA256:6aRZPwhjxDNgVIaXwaE9US9ZvUON3kzepoNH976w5vY agent
debug1: Authentication succeeded (publickey).
...
Hi liwenshen2000! You've successfully authenticated, but GitHub does not provide shell access.
...

如果出现下列报错，请优先检查上文涉及的配置文件内容，如换行符类型，末尾是否换行等。
> ssh-add -L
error fetching identities: agent refused operation

Git 签名

GPG密钥的GPG公钥

将GPG密钥的公钥导出。然后将输出内容粘贴至Github或者其他远程代码库等GPG配置中。就可以让代码库在推送代码后，认可这个GPG密钥签名的commits和tags。

> gpg --armor --export 82EF9F38F02BCA14
-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----

导出时是导出整个GPG密钥的公钥，包括主密钥和子密钥，因此无论使用的是主密钥ID还是子密钥ID，输出结果都是一样的。

配置Git

配置Git的GPG签名较为简单，首先在Git里设置用于签名的密钥的ID：

git config --global user.signingkey 1B3B3B59E5427BF0!

我这里指定了一个具体的GPG密钥进行签名，因此需要在在密钥ID的末尾加上感叹号。也可以使用主密钥，让Git自动选择其下的签名密钥用于签名，那么可以设置成主密钥的ID，不必加感叹号：

git config --global user.signingkey 82EF9F38F02BCA14

配置默认对所有commits和tags签名

git config --global commit.gpgsign true
git config --global tag.gpgSign true

延长密钥TTL

在日常使用各种git软件中的过程中，后台会使用ssh定期pull仓库，这时候频繁会弹出密钥过期的提示，可以在gpg-agent.conf加上以下配置，延长密钥的TTL。

输入一次密码有效1天，7天强制要求输入一次密码。

# default-cache-ttl 86400
# max-cache-ttl 604800
default-cache-ttl-ssh 86400
max-cache-ttl-ssh 604800

后记

实际上在Windows上使用GPG密钥进行Git签名和SSH认证，还是较为繁琐的。

推荐使用GpgFrontend等GUI前端进行GPG密钥生成和管理。

如果仅仅是为了在Github上给自己加上一个小绿勾，可以使用更为简单易用的SSH密钥进行签名和认证¹。

Github文档-使用SSH密钥签名 ↩︎

Mt7621 Vlan

Wed, 23 Feb 2022 11:24:57 +0800

首先要明白VLAN是什么，VLAN本质上就是对网络上数据包进行标记和隔离，在二层生效（IP层）。

VLAN常识

下面是一些术语。

VLAN ID (vid) 标记数据流所用的ID，取值为1~4094，用来划分网络，只有VID相同，才能认为他们在同一个网络。
- 0和4095是保留值，不要使用。
- 1是较为特殊值的值，不要轻易使用，除非你知道你自己再干什么。
Priority Code Point (prio) 包的优先级，取值为0（最低）~7（最高），我们并不关心这个值。
tag 字面翻译为 标记，有多重含义，注意融汇贯通。
- tag 作动词，指对包打上tag头
- tag 作形容词，意味着该包已经被打上tag头。
- tag 作名词，指该包所携带的tag头，主要包括vid和prio。
untag 与tag含义相反
- 作名词，指将被打上tag的数据流的tag去掉。
- 作形容词，指该包还未被tag。
Port VLAN ID (PVID) 每个端口（网口）特有的VID。
- 从该端口接受不带tag的包，都会被打上vid等于pvid的tag。
- vid等于pvid的tag的包从该端口发送，都会被untag。
- 对于其他包，根据安全设置，要么原样流入流出，要么被丢弃。

一些常识：

VLAN32指由tag头中vid为32的包所构成的网络，其余数字同理。
终端设备（普通电脑，手机，机顶盒等）未经特殊设置，只会使用untag的包。
这里的流入流出，是站在交换机角度而言：包从某个端口流入，指交换机接受到包。
网络包流入交换机后，必定携带tag，默认情况下端口的PVID值为1，这也是上文说不要轻易使用的原因。
MT7621内部包括一个5口交换机，实际上上却有7个端口，其中两个CPU端口，具体情况看下面。

VLAN观察

先ssh进入路由器运行命令，可以看见。我使用的是Newifi3进行讲解。

[RT-N56U_B1 /home/root]# switch vlan dump
 vid portmap eg-tag eg-con stag ivl fid
 1 1111--1 uuuu--t 0 0 1 -
 2 ----1-1 ----u-t 0 0 1 -
 4 ---11-1 ---tt-t 0 0 1 -

PVID:
port pvid prio matrix
 0 1 0 1111--1
 1 1 0 1111--1
 2 1 0 1111--1
 3 1 0 11111-1
 4 2 0 ---11-1
 5 1 0 ------1
 6 1 0 11111-1

首先看 PVID: 下的表格。

在port一列可以看见，路由器有0~6个端口7个端口。根据观察，猜测和查询资料，0~6端口分别对应为LAN4，LAN3，LAN2，LAN1，WAN，CPU1，CPU2。如果不确定，可以使用switch dump命令进行猜测和估计。

显然，pvid即每一个端口对应的pvid，无需赘述。值得注意的是，matrix的配置方式，matrix，指当前端口需要和其他哪些端口进行关联，后面讲解如何计算。

两个CPU端口某些路由器（如K2P）上可能分为CPU(LAN)和CPU(WAN)，后面再讲解区别。

回头看上面命令返回结果的第一大部分，表头为vid, portmap，eg-tag的表格，只关注前三列，无需关注后4列。

 vid portmap eg-tag
 1 1111--1 uuuu--t
 2 ----1-1 ----u-t
 4 ---11-1 ---tt-t

每一行指明了对应VID的VLAN的行为方式。

portmap 从左到右，分别指明当前VLAN是否使用的端口0~6。1 表示使用该端口，- 表示不使用该端口。
eg-tag 从左到右，分别指明当前VLAN使用端口的模式。u 表示untag，t 表示tag，- 表示不使用。ut 应该与portmap中 1 对应。

以vid为1的一行举例：

portmap 说明了VLAN1使用LAN1~~4接口和CPU2接口。即LAN1~~4口和CPU2口。

eg-tag 说明了对应端口的行为方式，

LAN1~~4接受untag的包，进入交换机后会被认为是VLAN1的包。VLAN1的包在这LAN1~~4流出时会被untag。

CPU2允许tag的VLAN1的数据流入流出。

实际上，这构成一个4口局域网局域网。

以vid为2的一行举例：

portmap 说明了VLAN2使用WAN接口和CPU2接口。

eg-tag 说明了对应端口的行为方式：

WAN接受untag的包，进入交换机后会被认为是VLAN2的包。VLAN2的包在WAN流出时会被untag

CPU2允许tag的VLAN2的数据流入流出

实际上，这构成了公网到路由器的连接。

公网数据包从WAN经VLAN2进入CPU，经过处理（拨号，防火墙，NAT等），再经过VLAN1发出，使得连接LAN1~4的设备可以接受互联网数据，反之同理。

注意：每一个端口只能有一个untag的VLAN，并且要和pvid对应

回头看，matrix 参数设置，即设置当前端口可能与哪些端口进行数据交换。计算方式为，只需要对portmap中当前端口不为0的行，进行按位取或。

VLAN配置

VLAN主要有以下几条命令

配置各个VLAN

switch vlan set [vid] [portmap] <stag> <eg_con> <eg_tag> - set vlan id and associated member

用于配置下面表头为 vid portmap eg-tag eg-con stag ivl fid 的表格内容。其中<stag> <eg_con>皆设为0。

配置端口pvid

switch pvid [port] [pvid] - set pvid on port 0~6

用于修改端口的pvid的值。

配置端口matrix

switch reg r [offset] - register read from offset
switch reg w [offset] [value] - register write value to offset

这里的 offset 取值为0x2004，0x2104，0x2204，…0x2604。注意只改变右起第3位的值，分别对应端口0~6的寄存器地址。

而寄存器内值 value 类似为0x4f0003，其中，右起5,6位即为matrix的值。

注意：matrix值在输入时应当反序，例如，LAN4口matrix值为1111--1，那么我们对应的二进制反序后应为1001111，十六进制值为4f，故输入命令：
switch reg w 0x2004 0x4f0003

我的配置脚本如下：

switch vlan set 1 1111001 0 0 uuuu--t
switch reg w 0x2004 0x4f0003
switch reg w 0x2104 0x4f0003
switch reg w 0x2204 0x4f0003
switch reg w 0x2304 0x5f0003
switch reg w 0x2604 0x5f0003
switch pvid 3 1

AP

配置Maven和Gradle镜像加速下载

Fri, 18 Jun 2021 16:33:03 +0800

无论是普通Java项目还是Android项目，往往都在使用Gradle作为构建工具。但由于无论是Maven仓库，还是gradle releases二进制文件都在国外，因此下载一般都很慢，因此需要使用国内镜像替换这些源。

因为Jcenter宣布关站（只读），我们只需使用阿里云的public仓库同时使用Maven Central和Jcenter仓库。

Maven配置镜像源

如果构建工具是Maven，那么修改用户目录/.m2/settings.xml文件，设置为阿里云镜像：

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
 <localRepository/>
 <interactiveMode/>
 <offline/>
 <pluginGroups/>
 <servers/>
 <mirrors>
 <mirror>
 <id>aliyunmaven</id>
 <mirrorOf>*</mirrorOf>
 <name>阿里云公共仓库</name>
 <url>https://maven.aliyun.com/repository/public</url>
 </mirror>
 </mirrors>
 <proxies/>
 <profiles/>
 <activeProfiles/>
</settings>

Gradle配置镜像源

如果是Gradle作为构建工具，比如Android项目，那么就需要修改项目的gradle配置。

 repositories {
// mavenCentral()
// jcenter()
// google()
 maven { url 'https://maven.aliyun.com/repository/google/' }
 maven { url 'https://maven.aliyun.com/repository/public/' }
 }

Gradle Releases镜像

每次打开一个Gradle的新项目时，都要下载一个Gradle的bin或all包，有时速度极为缓慢。

打开gradle/wrapper/gradle-wrapper.properties文件，修改其中的distributionUrl键值对，保持后面的文件名不变，将原网址中替换成腾讯云gradle镜像地址，重新打开项目即可。

#distributionUrl=https\://services.gradle.org/distributions/gradle-6.5-all.zip
distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-6.5-all.zip