共 2 篇相关文章
这篇从大家熟悉的数据库 truncate 指令切入，但立刻将目光转向了更早出现的 UNIX 系统命令。它清晰地对比了两者的异同：虽然都叫 truncate，但数据库版本保留表结构清空数据，而系统版本的操作对象是文件，不仅能清空至 0 字节，还能通过 -s 选项精确调整文件大小。 文章特别点出了文件 truncate 的一个实用场景：清理冗长的日志文件时，如果只想保留最头部的一部分关键信息，而非全部删除，普通的重定向清空（> log）就无能为力了。这时，truncate -s 4k log 这样的命令就能一步到位，既完成了清理，又保留了需要的上下文。 作者没有停留在命令本身，而是将它与日常运维中“清理日志但保留头尾”的痛点联系起来，让一个可能被忽略的系统工具，瞬间变得具体而有价值。这种从原理到实践的串联，使得知识点的讲解不浮于表面。
这篇讲的是 MySQL 5.1.X 版本主从复制中一个容易踩到的坑。作者发现，在特定配置下，master 上执行的 `TRUNCATE TABLE` 操作会“神秘消失”，并不会被同步到 slave 节点。 问题复现的关键在于一套经典的组合配置：使用 MySQL 5.1.31 企业版搭建主从，且服务器设置了 `transaction-isolation = READ-COMMITTED` 和 `binlog_format = MIXED`。在这种环境下，看似简单的表截断操作会绕过复制机制，导致主从数据不一致。 这其实是一个已知的 bug。其核心在于，在 `READ-COMMITTED` 隔离级别配合 `MIXED` 日志格式时，某些 DDL 语句（如 TRUNCATE）可能不会被正确地记录到 binlog 中，或者记录的方式无法让 slave 正确回放。对于依赖主从复制进行读写分离或备份的系统来说，这是一个需要警惕的隐患。 文章通过明确的重现步骤和参数配置，为 DBA 和开发者提供了一个清晰的排障参考。如果你在维护老版本的 MySQL 集群，这篇内容提醒你需要特别关注这类隐性的数据同步风险。
