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