QuestDB 数据不能新增问题解决方案
文档日期：2025年10月11日
问题发现时间：2025年10月11日
涉及表名：collection_map_node_data
数据量级：超过 1 亿条记录
问题现象：新数据无法写入表 collection_map_node_data，写入请求无响应或失败。
一、问题背景
collection_map_node_data 是系统核心时序数据表，长期持续写入。截至 2025 年 10 月 11 日，该表数据量已超过 1 亿条。当日发现新数据无法正常写入，影响业务正常运行。
经排查，初步判断为表数据量过大导致写入性能下降、资源竞争加剧或符号列（SYMBOL）缓存耗尽，最终导致写入阻塞或失败。
二、解决思路
由于 QuestDB 对大表的直接维护能力有限，且不支持行级 DELETE 操作，我们采用 “结构复制 + 数据迁移 + 表重命名” 的策略，重建一张轻量级的新表，仅保留必要数据，恢复写入能力。
核心步骤：
- 复制原表结构，创建新表。
- 将关键时间段的数据迁移到新表。
- 删除旧表。
- 将新表重命名为原表名，恢复业务写入。
三、详细解决方案
步骤 1：复制表结构并创建新表
在 QuestDB Web Console 中执行：
-- 查看原表结构（用于参考）
SHOW CREATE TABLE collection_map_node_data;
根据输出的建表语句，创建新表 collection_map_node_data_1，确保结构完全一致（包括列类型、TIMESTAMP、PARTITION BY 等）：
步骤 2：迁移关键数据到新表
2.1 迁移 2025 年全年数据（保留近期数据）
INSERT INTO collection_map_node_data_1
SELECT * FROM collection_map_node_data
WHERE timestamp >= \'2025-01-01T00:00:00.000000Z\';
说明：此操作将 2025 年 1 月 1 日至今的数据迁移到新表，确保业务连续性。
2.2 （可选）补录近期数据（如增量未同步）
若在迁移过程中有新数据写入旧表，可补充迁移最近时间段的数据：
INSERT INTO collection_map_node_data_1
SELECT * FROM collection_map_node_data
WHERE timestamp >= \'2025-09-10T00:00:00.000000Z\'
AND timestamp < \'2025-10-10T00:00:00.000000Z\';
步骤 3：验证数据完整性
-- 检查原表总数据量
SELECT count() FROM collection_map_node_data;
-- 检查新表数据量
SELECT count() FROM collection_map_node_data_1;
-- 检查新表最新数据是否正常
SELECT * FROM collection_map_node_data_1 ORDER BY timestamp DESC LIMIT 100;
确保新表数据量合理，且时间戳连续、数据完整。
步骤 4：删除旧表
确认新表数据无误后，删除旧表以释放资源：
DROP TABLE collection_map_node_data;
警告：此操作不可逆，请确保已备份或确认数据已迁移。
步骤 5：重命名新表为原表名
将新表 collection_map_node_data_1 重命名为 collection_map_node_data，恢复业务连接：
RENAME TABLE collection_map_node_data_1 TO collection_map_node_data;
注意：确保目标表名不存在。如果之前删除失败，可先执行： DROP TABLE IF EXISTS collection_map_node_data;
步骤 6：验证写入功能恢复
执行一条测试写入：
INSERT INTO collection_map_node_data
VALUES(\'2025-10-11T16:00:00.000Z\', \'test_device\', 99.9, \'Beijing\');
查询确认数据已写入：
SELECT * FROM collection_map_node_data
WHERE timestamp >= \'2025-10-11T16:00:00.000Z\';
四、问题根因分析（推测）
| 可能原因 | 说明 |
| 符号列缓存耗尽 | SYMBOL列（如device_id）基数过高，超出默认capacity（100万），导致写入失败。 |
| 磁盘/内存资源不足 | 大表占用大量资源，写入缓冲区满，新数据被拒绝。 |
| 写入锁竞争 | 长时间查询或大插入操作阻塞写入。 |
| 分区过多 | 按天分区的表超过 3 年，分区数过多可能影响元数据管理。 |
建议：检查 QuestDB 日志（~/.questdb/log/questdb.log）确认具体错误信息。
五、后续优化建议
- 定期归档旧数据
建立数据归档机制，将超过 1 年的数据迁移到归档表或冷存储。
- 监控表大小和资源使用
使用 Prometheus + Grafana 监控 QuestDB 的磁盘、内存、表行数等指标。
- 调整 SYMBOL 列容量
若设备数超过 100 万，建表时显式设置更大 capacity：
device_id SYMBOL capacity 5000000 CACHE
- 按业务周期分表
考虑按月或按季度创建新表，避免单表无限增长。
- 启用 WAL（可选）
对于高可用场景，启用 WAL 可提高写入可靠性。
六、总结
本次通过 重建表结构 + 数据迁移 + 重命名 的方式，成功解决了 QuestDB 大表写入阻塞问题。新表 collection_map_node_data 已恢复写入能力，系统运行正常。
该方案适用于 QuestDB 在无法直接维护超大表时的应急恢复，建议结合定期维护策略，避免问题再次发生。
状态： 问题已解决
七、【补充】QuestDB数据删除
截至 2025 年，QuestDB 在大多数部署模式下仍然对 DELETE 操作有严格限制，尤其是在默认的“追加优化”（append-optimized）表上。
正确答案：QuestDB 目前不支持通用的、基于任意条件的 DELETE 语句
尽管早期文档或社区讨论中提到过实验性支持，但 在生产环境中，QuestDB 本质上是一个为高性能写入和查询设计的时序数据库，它并不像传统数据库那样支持完整的 DELETE 操作。
详细解释
1. QuestDB 的设计哲学
QuestDB 被设计为：
- 高吞吐写入
- 低延迟查询
- 时间序列优先
为了实现高性能，它采用列式存储和追加写入（append-only）模型。删除和更新操作会破坏这种性能优势，因此被有意限制。
2. DELETE 语句的现状
| 功能 | 支持情况 | 说明 |
| DELETE FROM table WHERE condition | 不支持（或受限） | 不能像 MySQL 那样随意删除行 |
| 基于主键或符号列删除 | 不支持 | QuestDB 没有传统意义上的主键 |
| 基于时间分区的删除 | 部分支持（通过DROP PARTITION） | 唯一可行的“删除”方式 |
正确的“删除”方法：删除整个时间分区
如果您想删除某个时间点之前的所有数据，唯一可靠的方法是删除整个分区。
示例：删除 2024 年 7 月之前的分区
-- 删除 2024 年 6 月及更早的分区
ALTER TABLE collection_map_node_data
DROP PARTITION LIST \'2024-06\', \'2024-05\', \'2024-04\';
或者使用时间范围，【我使用此方法】：
-- 删除指定时间范围的分区
ALTER TABLE collection_map_node_data
DROP PARTITION WHERE timestamp < \'2024-07-01T00:00:00.000000Z\';
注意：表必须是按时间分区的（如 PARTITION BY DAY/MONTH/YEAR）。删除的是整个分区，不能只删分区内的部分行。操作是不可逆的。
