Clickhouse删除更新遇到阻塞

最新推荐文章于 2025-05-05 11:10:05 发布
最新推荐文章于 2025-05-05 11:10:05 发布
阅读量1.4k 收藏 1
点赞数 2
CC 4.0 BY-SA版权
分类专栏： clickhouse 文章标签： sql 大数据 数据库架构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zhangbingtao2011/article/details/121704805
本文探讨了在ClickHouse中遇到的SQL执行阻塞问题，如何通过查询mutations表找到阻塞的SQL，并使用KILL MUTATION命令解除阻塞，确保SQL执行成功。重点介绍了定位问题和操作方法。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Clickhouse删除和更新都是异步进行的，有时候因为某种原因，sql执行，但是没有出现执行后的结果，因为sql执行遇到了阻塞。

查询阻塞的sql：

select * from system.mutations where is_done  = 0；

将阻塞的sql杀掉：

KILL MUTATION WHERE database = 'aaa' AND table = 'user';

再次查询阻塞确保已经kill掉。

执行sql，好使。

《ClickHouse企业级应用：入门、进阶与实战》1 全面了解ClickHouse
AI天才研究院
01-31 1万+
近年来，ClickHouse发展势头迅猛，社区、大厂纷纷跟进使用。面对万亿级的数据查询分析也能做到亚秒级响应。那么，ClickHouse 到底是何方神圣？为什么如此受青睐？各位看官，欲知 ClickHouse 为何方神圣，且往下看。本章我们先来了解什么是ClickHouse，内容包括ClickHouse是什么，它具有哪些特性，适用哪些应用场景等。1.1 ClickHouse 概述本节介绍 ClickHouse 是什么、发展历程，以及ClickHouse在 OLAP 生态中的位置。同时，简单介绍了 OLAP
Clickhouse引擎—数据库引擎
热门推荐
09-16 4万+
主要介绍了Clickhouse的 数据库引擎Atomic 是默认的数据库引擎其他的引擎我们可以根据具体的业务场景来合理使用。
[ClickHouse] 将 mutation 操作由异步非阻塞改为阻塞
weixin_42902669的博客
03-06 3007
ClickHouse 中的 mutation 操作(update/delete) 默认是异步执行的, 这会导致一种情况的出现: 删除的数据在一段时间内还能查询到. 在非事务性的使用场景中这个设置可以加快处理速度, 并且不会影响后来数据的添加, 但在要求事务性的使用场景中(比如新增数据依赖历史数据), 这个设置会导致后加的数据出现错误. 为了解决这个问题, 尝试了下面两种方法 通过查询 system.mutations 表的 is_done 字段来判断一个操作是否已完成, 在 is_done = 1 之前人
clickhouse—表操作失败，无法进行表结构的修改、也无法删除表
qq_42880977的博客
02-04 866
对应的进程删除失败(KILL QUERY WHERE query_id='*****' )。但是查询之后能看出是String类型转Date类型的进程一直在，删不了。分析得知，肯定是更新表结构的语句卡住了，执行kill mutation where database='****' and table='****';语句之后再查进程表，删除成功。在一次表结构的modify之后，集群中的一个节点不能正常进行表结构的修改、表也删除不了。所幸，表的插入和查询操作无异常。
【clickhouse-4】Updating and Deleting ClickHouse Data
m0_69378371的博客
04-28 446
ClickHouse 作为一款面向 OLAP 场景的数据库，其更新和删除操作与传统 OLTP 数据库有显著区别。
clickhouse（十四、分布式DDL阻塞及同步阻塞问题）
yyoc97的专栏
08-22 2641
验证处理clickhouse 分布式ddl和同步阻塞问题
ClickHouse删除数据之delete问题详解
qq_654603797
02-22 2万+
背景：
【clickhouse踩坑记录】clickhouse数据删不掉
weixin_44505713的博客
06-05 8520
背景 今天做数据同步时，需要进行先删除数据再写数据这一步操作。但是执行删除数据sql后，数据没被删掉，仍然还可以查询到。但执行删除语句返回的结果并没有报错。 // 删除代码 alter table ${db}.${table} on cluster ${cluster} delete where event_date between '2021-05-05' and '2021-06-03' // 查询代码 select * from ${db}.${table} where event_date bet
clickhouse基础教程
Im ok的博客哦
05-06 1万+
一、基础概念 Clickhouse由俄罗斯Yandex公司开源的数据库，专为OLAP而设计。 Yandex是俄罗斯最大的搜索引擎公司，官方宣称ClickHouse 日处理记录数”十亿级”。 发布之初跑分要超过很多流行的商业MPP数据库软件，对标老东家HP的Vertica和GP 官方的性能测试显示比vertica快5倍，比GP快10倍。 但是： clickhouse直接可以安在各种版本的Linux系统上，macos可以通过docker来安装 官方没有提供设计和架构文档，只有开源的C++源码 不理睬Hadoop
万字详解：ClickHouse 存算分离架构与数据一致性事务机制实现
AI天才研究院
03-31 241
成本效益存储成本降低60%，计算资源利用率提升40%弹性扩展支持秒级扩容千核计算资源数据强一致金融级事务支持能力云原生融合无缝集成现代云基础设施未来随着软硬协同优化技术的发展，ClickHouse有望在实时分析、HTAP等领域开创新的技术范式。多云/混合云部署环境需要弹性伸缩的SaaS应用强一致性要求的财务分析系统PB级历史数据交互式查询本文介绍的是如何实现ClickHouse的存算分离架构和数据一致性的事务机制，需要万字详解。首先，我得先理解存算分离是什么。
第十阶段【ClickHouse基础及运维】02：ClickHouse引擎
最新发布
weixin_40612128的博客
05-05 59
ClickHouse引擎
ClickHouse增加删除更新操作
haveanybody的博客
05-22 6654
前面我们已经介绍过 ClickHouse 是列式存储数据库，并且是按照有序存储、且按照索引粒度建立稀疏索引，所以 ClickHouse 是不擅长做 update/delete 操作的，对于需要经常变化的数据，也不建议使用clickhouse。但是并不是说clickhouse就不能更新数据，clickhouse提供了一种基于alter语句的“突变”（mutations）操作来实现更新/删除操作。在使用mutations操作之前需要注意： mutations操作需要重置分区，是一种“很重”的操作，更适用于操作
clickhouse在执行alter table update delete等命令后数据没有更新
weixin_44313745的博客
09-15 2284
我们所说的Mutation也是异步的操作，是Clickhouse中的工作线程池来完成。对于mutations执行失败的话，先去查询system.mutations的任务，查看is_done=0的数据，并且看下latest_fail_reason的原因。如果发现问题不是sql的原因，则删除mutations再尝试执行删除或者更新，如果是sql或者其他原因，查询找到原因解决再执行删除或者更新。至于之前的为什么没执行成功，也没有去探究，只是当时发现线上不少mutations被卡住，未执行成功。
clickhouse Mutations删除操作报错及解决方案
王者丶丿风范
04-12 6156
1. clickhouse 执行删除语句后查询数据仍旧存在，等待数分钟后依然存在 2. 查询 system.Mutations 表 ```sql select * from system.mutations where is_done = 0; ```发现任务在突变表中状态一直是未执行 3. 查阅 /var/log/clickhouse-server/clickhouse-server.err.log 日志发现如下报错 2021.04.09 10:59:12.971073 [ 6363 ] {}
高级DBA教你clickhouse数据库查询正在执行的SQL语句的汇总方法全网最详细
nasen512的博客
02-27 5285
ClickHouse 中更新数据的语句是异步执行的，应用并不知道 ClickHouse 何时能更新数据，如果要做到强一致性，需要应用反查确认。请注意，这只是一个基本示例，具体的查询可能会根据你的 ClickHouse 安装和配置而有所不同。请注意，这只是一个基本示例，具体的查询可能会根据你的 ClickHouse 安装和配置而有所不同。表中的字段含义可能会因 ClickHouse 的版本和配置而有所不同。表中的这些字段，你可以了解查询的执行情况、性能指标以及用户活动等信息，有助于监控和优化数据库的使用。
clickhouse 更新数据或者删除数据失败
wangpeng52758的博客
10-25 2537
clickhouse 更新数据或者删除数据失败
19、ClickHouse企业中常见的25种用法
Java__EE小白成长之路
02-16 2392
ClickHouse企业中常见的20种用法。
dbeaver连接clickhouse时：Unexpected driver error occurred while connecting to the database
weixin_45493694的博客
12-21 9153
用dbeaver连接clickhouse时，报错Unexpected driver error occurred while connecting to the database； 第一种： 大概率是因为clickhouse的配置文件/preprocessed_configs/config.xml文件中的 <listen_host>::</listen_host> 为注释状态，解开注释。 第二种： 也就是我个人的情况，我用docker容器启动的clikehouse镜像
数据库1000万数据查询很慢，如何优化
02-18
<think>嗯，用户问的是数据库里有1000万数据查询很慢，怎么优化。这个问题挺常见的，但具体怎么回答呢？首先得考虑用户可能的情况。用户可能是个开发人员或者运维，遇到了性能问题，需要优化查询速度。首先，我应该从基础的优化步骤开始，比如索引、查询语句优化，然后再到分库分表这些高级方法。 首先想到的是索引。没有合适的索引，查询肯定会慢。但用户可能已经加了索引，但效果不好，这时候要考虑索引是否合理，比如是不是覆盖索引，或者有没有索引失效的情况，比如使用了函数或者类型转换。另外，复合索引的顺序是否正确，选择性高的字段应该放在前面。 然后是SQL语句的问题。用户可能写了复杂的查询，比如用了SELECT *，或者有JOIN、子查询，导致效率低下。需要建议他们只查询需要的字段，优化JOIN的条件，避免全表扫描。还有执行计划的分析，用EXPLAIN看看有没有全表扫描或者临时表的使用。 接下来是数据库设计方面。表结构是否合理，字段类型是否合适，比如用VARCHAR代替TEXT，或者是否过度范式化导致需要频繁JOIN。分区表也是一个选项，特别是按时间或者范围分区，可以减少扫描的数据量。 硬件和配置方面，可能用户的服务器内存不足，或者磁盘速度慢，导致IO瓶颈。调整数据库的配置参数，比如缓冲池大小，连接数等，也可能有帮助。不过这部分可能需要管理员权限，用户不一定能操作，但至少可以提出来让他们检查。 如果数据量持续增长，可能需要考虑分库分表，把大表拆分成多个小表，或者分到不同的数据库实例里。不过分片会带来复杂度，比如事务管理和查询路由，需要权衡利弊。另外，读写分离也是一个方法，把读和写分开到不同的服务器，减少主库的压力。 缓存方面，引入Redis或Memcached缓存热点数据，减少直接查库的次数。或者数据库自身的查询缓存，但要注意缓存失效的问题。还有异步处理，比如把统计类的查询移到从库或者用队列异步执行，避免影响实时操作。 归档历史数据也是一个点，把不常用的数据移到历史表或者冷存储，减少主表的数据量。定期清理无用数据，保持表的大小在可控范围内。 最后，如果这些都不够，可能需要升级到更强大的数据库，比如分布式数据库，或者使用列式存储如ClickHouse，不过这些可能需要较大的架构调整。 用户可能需要的是一步步的优化步骤，从简单到复杂，先检查索引和SQL，再调整设计，最后考虑架构层面的改变。还要注意不同数据库系统的特性，比如MySQL、PostgreSQL可能有不同的优化技巧，但用户没有具体说明，所以回答要通用一些。 另外，可能用户没有监控工具，不知道慢查询的具体原因，所以建议他们先分析慢日志，找出具体的慢查询语句，再针对性优化。总之，整个思考过程需要覆盖各个层面的可能性，从低成本的优化到高成本的架构调整，给出全面的建议。针对</think> 1000 万级别数据的查询优化，需要从**数据库设计、索引、SQL 语句、硬件配置、架构调整**等多维度入手。以下是常见优化策略： --- ### 一、基础优化（低成本优先） 1. **索引优化** - 确保 WHERE、JOIN、ORDER BY 涉及的字段已建立**合适索引**（避免全表扫描）。 - 使用**覆盖索引**（索引包含查询所需字段，避免回表）。 - 注意索引的**选择性**（区分度低的字段如性别、状态不适合单独建索引）。 - 避免索引失效场景（如对索引字段使用函数、隐式类型转换、`LIKE '%xx'`）。 2. **SQL 语句优化** - 避免 `SELECT *`，只查询必要字段。 - 减少复杂 JOIN 或子查询，优先用 EXISTS 替代 IN。 - 分页优化：大偏移量分页改用 `WHERE id > [上一页最大值]` 替代 `LIMIT N,M`。 - 使用 `EXPLAIN` 分析执行计划，关注 `type`（扫描类型）和 `rows`（扫描行数）。 3. **表结构优化** - 合理设计字段类型（如用 INT 而非 VARCHAR 存储数字）。 - 垂直拆分：将大字段（如 TEXT）分离到副表，减少主表体积。 - 适度反范式化：通过冗余字段减少 JOIN 操作。 --- ### 二、进阶优化（中高成本） 4. **分区表（Partitioning）** - 按时间、范围等维度分区，缩小查询扫描的数据量（例如按月份分区）。 - 注意分区键的选择，避免跨分区查询。 5. **读写分离** - 主库处理写操作，读请求分流到多个从库（适合读多写少场景）。 6. **缓存层** - 高频查询结果缓存到 Redis/Memcached，减少直接访问数据库。 - 使用数据库内置查询缓存（如 MySQL Query Cache，注意命中率）。 7. **异步处理** - 耗时统计类查询通过消息队列异步执行，避免阻塞实时请求。 --- ### 三、架构级优化（高成本） 8. **分库分表** - **水平拆分**：按哈希、范围等规则将单表拆分为多个小表（如 `user_0`、`user_1`）。 - **垂直拆分**：按业务模块将数据库拆分为多个子库（如订单库、用户库）。 - 引入中间件（如 ShardingSphere、MyCat）管理分片路由。 9. **列式存储与 OLAP 引擎** - 分析类查询迁移至列式数据库（如 ClickHouse、HBase）。 - 升级 SSD 硬盘，提升 IOPS。 - 增加内存，扩大数据库缓冲池（如 MySQL 的 `innodb_buffer_pool_size`）。 - 调整并发连接数、线程池等参数（需根据负载测试）。 --- ### 四、数据治理 11. **归档与清理** - 定期将历史数据迁移到归档表或冷存储（如 S3）。 - 删除无效数据（如软删除的冗余记录）。 12. **监控与分析** - 启用慢查询日志（如 MySQL 的 `slow_query_log`），定位瓶颈语句。 - 使用 Prometheus + Grafana 监控数据库负载。 --- ### 示例场景：分页查询优化 **原始 SQL（慢）：** ```sql SELECT * FROM orders ORDER BY id LIMIT 1000000, 10; -- 扫描前 100 万行 ``` **优化方案：** ```sql SELECT * FROM orders WHERE id > (SELECT id FROM orders ORDER BY id LIMIT 1000000, 1) ORDER BY id LIMIT 10; -- 通过子查询直接定位起始 ID ``` --- ### 总结 - **优先排查索引和 SQL**（80% 的性能问题源于此）。 - **分库分表是最后手段**，需评估复杂度与收益。 - 结合业务场景选择方案（如 OLTP 与 OLAP 优化方向不同）。 - 测试验证：任何改动需通过压力测试（如 sysbench、JMeter）。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值