五岁博客

一台物理主机只有 4GB 内存，却同时跑着 4 台、每台配置 4GB 的虚拟机，账面上要 16GB。

主机没崩，业务还正常跑。

这事儿听起来违反常识，但在虚拟化和云平台里天天发生。

系统盘越用越满，/var/lib/mysql 眼看要爆。

云磁盘数据盘 /data1 空着一大片，最直接的办法就是把 MariaDB 的数据目录整个搬过去。

某些情况下也需要更改数据库的数据目录位置，不再使用默认的 /var/lib/mysql。

对一个 Decimal(18,8) 列执行 sum，拿出来的结果类型却变成了 Decimal(38,8)。

如果你用的是 clickhouse-go 老版本，紧接着就会看到一行报错：Decimal128 is not supported。

这事我自己踩过。

当时查的是库存金额，建表时字段明明写的 Decimal(18,8)，聚合一下程序就崩了，盯着错误日志愣了好一会儿。

刚上手 ClickHouse 那阵，我被分组查询坑得不轻。

写惯了 MySQL 的 GROUP_CONCAT 和 GROUP BY 后随手取列，到了 ClickHouse 全报错。

这篇把我趟过的几个坑整理一下，重点说清楚「分组后怎么正确取每组第一条记录」。

一个普遍的疑问

很多人从小在农村长大，可能都有过这样的疑惑：家里的化粪池好像从来没有人来抽过粪，也没见过什么吸粪车，但它就是能年复一年地用下去，既没有臭气熏天，也没有粪便溢出来。这到底是怎么回事？ 是化粪池有什么神奇的魔法，还是我们忽略了什么？

ClickHouse 查询快，但删除和更新一直是它的软肋。

VersionedCollapsingMergeTree 是官方给出的一个折中方案：不真删数据，而是再插一条「抵消行」，让后台合并时把新旧记录成对消掉。

我之前在一个用户状态表上踩过它的坑，SELECT * 出来的数据对不上，折腾了挺久才搞明白它的脾气。