@villivateur 对，这是关键，读音或者拼写或者大小写不对有时候会导致混淆，平白增加沟通成本甚至导致潜在的错误

这鼻音吞得，很有一种东洋 Toyo 东京 Tokyo 的感觉

老大的主要作用是跟平级的其它老大撕逼，跟更大的老大讨钱。

@allenzhangSB 我上次拿来测试的物理机系统是 Debian 13 ，MySQL 官方 deb 包只到 12 的，库依赖有问题，我又懒得自己编译了。今天找了一台 Debian 12 的虚拟机做了测试。所在的物理机也比较老了，E5-2360 的。虚拟机是 6C 12G ，存储是来自 SSD 加速的 HDD 阵列分的 LUN 。

安装了 PG 和 MySQL ，PG 来自 PGDG 的 apt repo ，版本 15.5 ，MySQL 来自 Oracle 官方 deb ，版本 8.0.35 。两者都没做任何 tuning 。

测试数据：先在 PG 上生成，再导出后导入到 MySQL 去。
数据生成语句：
create table t(i integer, v integer);
insert into t (select i, random()*100::integer from generate_series(1, 100000000));

测试语句：
select count(1) from t;
select sum(v) from t;
select v, count(1) from t group by v;

测试一个系统时关掉另一个系统。不过没重启服务器。

测出来的结果
pg15
count: 2.746s
sum: 3.001s
group: 7.109s

mysql80
count: 4.67s
sum: 76.48s
group: 100.95s

EV 的只能买

是否设置默认值，取决于是否有业务上合理的默认值。
大多数涉及人员信息的表，性别字段有默认值是没道理的；但是预设主要目标用户群是特定性别但又不排斥其它性别的社交软件，性别字段有默认值就是合理的。

要在文件名里写小作文的话只能用 Windows 了。Linux 下用 SMB ，文件名终究还是要落盘到本地文件系统的。

刚才忽然好奇测试了一下 PostgreSQL ，在自己陈年老机上，i4-4460 ，32G 内存，没 tune 过参数的 PG16 ，生成了一亿条随机数，全表 sum 一下 1972.434 ms

@zuotun 抱歉，不看动漫，不懂“检测到字幕文件和系统字体之间的缺失部分”是什么软件在什么场景怎么操作的

@sleepingdog 不需要，zerotier 相当于在你电脑上装了一个虚拟网卡，你访问家里的设备走的是这个虚拟网卡，而不是无线网卡

OP 配得上百度

首先要想明白，zerotier 是个 VPN ，里面的 P 是啥意思，private ，就是说 VPN 链路建立起来之后两端都是你自己可控的设备或网络，不是外部的公网，相当于你在自己放在外面的电脑和家里的路由器上各插了一块看不见的“网卡”并用看不见的“网线”连起来，外网根本摸不到，你要在上面做啥策略？
真要在 VPN 上做策略，那是类似公司不同分部之间的网段用 VPN 连通起来根据部门之间的访问限制需求来做的，前提是你要限制不可控的“别人”。

因为，很久以前的说法是 MySQL 上了 2000 万就要分库分表……所谓轻松 1 亿是针对以前年代的硬件和 MySQL 版本上 OLTP 类系统哪怕做好索引和优化也扛不住这个量的数据来说的。

Linux 下不是/usr/local/share/fonts 下面建个子目录把字体扔进去就行了？

主流 RDBMS 的差别不至于对学习有很大影响。
另外，一些不错的教程，比如《 SQL 基础教程》/《 SQL 进阶教程》系列，《 SQL 经典实例》等，都考虑到了主流 RDBMS 的差异，在讲到涉及语法差别的地方会做说明。
如果要把 SQL 本身学得更深，得看《 SQL 反模式》、《 SQL 沉思录》之类的。
再深下去要学各种系统的内部原理，比如优化器之类的。

呃，删掉第一个“不做”

你是觉得在 zt 接口上不做开了两个 ACCEPT 不做更严格的策略不安全？可能想多了吧。

脚踏板

@hez2010 不是 KHCU ，是 HKCR ，相当于 HKCU 和 HKLM 里部分内容组合的一个视图