是的，TRUNCATE ONLY在PostgreSQL中仅对继承表有效，对声明式分区父表加ONLY会报错；正确做法是直接TRUNCATE具体分区名（如logs_202301），不加ONLY，即可安全、快速清空单个分区。
TRUNCATE ONLY对分区表是否真的只清空当前分区
是的，TRUNCATE TABLE ... ONLY 在 PostgreSQL 分区表中确实只作用于指定的分区（即叶子表），不会级联清理其父表或其他子分区。但前提是：你明确指定的是**具体的分区表名**，而不是父表名加 ONLY —— 后者会报错或无效。
常见误解是写成 TRUNCATE TABLE parent_table ONLY，这在分区表上不生效，因为 parent_table 是声明式分区的“逻辑表”，本身不存数据，也没有存储行；ONLY 对它无意义，PostgreSQL 会直接忽略 ONLY 并尝试 truncate 整个继承树（如果启用了 INHERITS）或报错（声明式分区下通常报 ERROR: cannot truncate a partitioned table）。
- ✅ 正确做法：先查出目标分区名，再对那个具体分区执行
TRUNCATE TABLE partition_name（无需ONLY） - ⚠️
ONLY关键字在声明式分区中对父表无效，仅对传统继承表有意义 - ? 可用
\d+ parent_table或查询pg_inherits确认分区关系
如何安全、快速定位并清空某个时间范围的分区
生产环境常按时间（如 created_at）做范围分区，要清空 2023 年 1 月数据，不能靠猜表名，得从系统目录查。
PostgreSQL 12+ 中，分区名通常由用户定义（如 logs_202301），但更可靠的方式是通过 pg_partitioned_table 和 pg_inherits 关联查询：
SELECT child.relname AS partition_name FROM pg_inherits i JOIN pg_class parent ON parent.oid = i.inhparent JOIN pg_class child ON child.oid = i.inhrelid WHERE parent.relname = 'logs' AND pg_get_expr(child.relpartbound, child.oid) LIKE '%2023-01%';
查到表名后，直接 TRUNCATE TABLE logs_202301 即可。注意：
- TRUNCATE 不走 WAL 日志重放（除非开启
log_statement = 'all'），比 DELETE 快得多，且不触发触发器 - 但会持有
ACCESS EXCLUSIVE锁，期间该分区不可读写 - 若分区上有外键引用，TRUNCATE 会失败，需先
ALTER TABLE ... DROP CONSTRAINT或用TRUNCATE ... CASCADE（慎用）
TRUNCATE单个分区 vs DROP + CREATE PARTITION 的性能差异
清空分区时，有人倾向 DROP TABLE partition_name 再重建，认为更“彻底”。实际上，TRUNCATE 更轻量、更安全：
- ✅
TRUNCATE保留表结构、索引、约束、权限，不重新解析 DDL，毫秒级完成（无论原数据多大） - ❌
DROP + CREATE需重放建表语句、重建所有索引（可能数秒甚至分钟）、重赋权限、且中间存在窗口期导致查询失败（如应用还在查这个分区） - ⚠️ 若分区有
DEFAULT分区，DROP 后新数据可能误入 default，而 TRUNCATE 不影响分区路由逻辑
唯一例外是：你确定该分区永久不用了，且想释放磁盘空间给操作系统（TRUNCATE 后空间仍被 PostgreSQL 占用，只是标记为可复用）——此时才考虑 DROP。
为什么有时 TRUNCATE 分区会卡住或报错
常见原因不是语法问题，而是并发或依赖干扰：
- ? 正在运行的 SELECT / UPDATE 持有
ROW SHARE或更强锁？TRUNCATE 需要ACCESS EXCLUSIVE，会被阻塞。可用SELECT * FROM pg_locks WHERE relation = 'partition_name'::regclass查看 - ? 分区上有未提交事务（尤其是长事务），会导致 TRUNCATE 等待，超时后报
canceling statement due to lock timeout - ? 外键指向该分区？即使外键定义在父表上，PostgreSQL 也会检查子表级约束，报
cannot truncate a table referenced in a foreign key constraint - ? 分区表开启了
enable_partition_pruning = off？不影响 TRUNCATE，但容易让人误以为分区机制失效，其实无关
真正关键的点往往藏在锁和事务状态里，而不是 SQL 写法本身。
