你这是要投运维岗吗？

你牛个屎

你只看互联网厂家的产品，那不就是互联网摄像头嘛。

从有电子计算机开始到现在，standard X86 PC 这样高度标准化的、内部也高度开放的计算机才是个异数，你却把它作为常态用来参考，以批判高度定制化和一体化的消费电子产品的封闭性。

@yinxs2003 这样阴阳怪气就没意思了。

@yinxs2003 PostgreSQL 和 MySQL 都是关系数据库，个关系数据库，关系数据库，系数据库，数据库，据库，库。 要比也是跟 Oracle 、MS SQL Server 、IBM DB2 、Sybase 以至 SQLite 这些同为关系数据库来比。你拿去跟非关系数据库比，觉得这些非关系数据库没有而 PostgreSQL 有的东西“看起来怪怪的”而 MySQL 没有则算是正常，这比较实在是没比到点上。而 PostgreSQL 有但 MySQL 没有的特性，恰恰在上面说的这些关系数据库系统里大部分也有对应（虽然语法不一定一致）。从这个角度来讲，MySQL 反而是另类。如果实现得比较齐备和规范的关系数据库系统在你眼里是“小众的东西”，那真是隔行如隔山，三观不同无法强融了。

@me1onsoda 注意他说的是“当年”……在中国互联网早期，很多小站站长都是只会 Windows 的。他们在自己 Windows 台式机上开发完了就直接 ftp 上传到 Windows 虚拟主机（注意是 virtual hosting ，不是虚拟机 virtual machine ）。另外，有点搞笑的是，MySQL 里各种不规范的坑，对于那个年代的小站站长们来说反而是容易入门的，比日期是 0000-00-00 ，比如 group by 了但是可以在 select 后面写既不聚合有不在分组中的表达式……这些不规范写法都能通过，很好地适应了互联网草根技术人“管它嬢的规范不规范先跑起来再说，老子没心思去搞你的几范式也顾不上清洗不规范数据”的偏好。

换句话说，虽然你可能不想用 CentOS 里已打包的老版本组件，或者你需要的组件根本没有打好的包，需要自己编译安装，但最好看看人家已打好的包是怎么做的，想想其中的道理，一些关键的做法尽量遵循已有的 best practice 。

不要用同一个可以交互登录的普通用户（ uid >= 1000 or 500 ）又做文件安装又运行程序。

用 root 来安装，程序、配置、只读数据文件的 owner 是 root ，但是运行时的身份是新建的专用用户，可写数据文件的 owner 也是这个专用用户。这个用户用 useradd 创建时加 -r 参数，尽量不要有实际的 home 和 shell 。

这是老派运维的标准做法。也是 deb 、rpm 打包的惯例。

其实很多所谓 IT 人，包括程序员，对桌面操作系统上的高级操作都一脸懵圈

细看下来，其实可以分几种情况：

1. 大体知道怎么读，但因为受母语（普通话/方言）的音位干扰导致发音不准确，比如上面说的英语里 gen ，有人觉得更读汉语 zhen 不可思议，有人觉得读汉语 jin 更不可思议……其实跟方言音位有关……还有更典型的，很多中国人区分不开 s 和 th
2. 大体知道怎么读，但因为对词形变化导致的读音变化掌握不到位导致猜测的发音不准确，比如上面说的 original vs origin
3. 混淆了拼写相近的不同单词而读错，比如 device vs driver ，module vs model😭这种错误，可能不只是读错，很可能在写代码的时候也有一定概率写错
4. 对专有名词、（英语里的）外来语单词、自造词和借用词，没考究其读音而读错……对，说的就是 Ubuntu 、Kubernetes 还有 Gnome （表示软件名的时候 G 要单独发音，而单词 gnome 里 g 不发音）……

1 和 2 对于以交流为目的来说一般不会有大问题。
4 在不产生混淆的情况下也不是大问题，但 OP 说到这种情况并不是，产生混淆了，而且这读音差得大得都没道理。
3 我认为是很严重的问题。就是当事人英语词汇能力太差。不是发音不准确或口音重的问题。

@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 的只能买

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