TranquilXuan

Doris 分区分桶设计与数据倾斜问题排查实战某天下午，业务方反馈「实时大盘」中今日订单统计查询耗时从 200ms 飙升至 3s，且伴随 BE 节点 CPU 使用不均。打开监控发现，集群中 3 个 BE 节点的磁盘 IO 和 CPU 出现了明显的高低差异——这正是典型的数据倾斜信号。对于依赖 MPP 并行查询的 OLAP 引擎而言，数据分布不均会让部分节点成为短板，拖垮整体查询性能。本文从原理出发，通过电商订单与日志分析两个实战场景，逐步演示 Doris 分区分桶的设计范式、倾斜排查方法和动态分区最佳实践。 1. 分区与分桶：把大象装进冰箱的正确姿势Doris 的表数据逻辑上被划分成 分区 (Partition) 和 桶 (Bucket/Tablet) 两级组织： 分区：按时间、地域等维度做逻辑切分，作用是管理数据生命周期和查询裁剪。一个分区通常对应一个目录，可以独立地进行备份、删除。 分桶：在一个分区内部，按指定列的 Hash 值将数据打散成多个物理 Tablet。Tablet 是 Doris 中最小的数据存储和负载均衡单元，分桶的均匀性直接决定了查询并行度和节点负载 ...

MySQL 8.0窗口函数实战：解决TopN与排名问题业务开发中经常遇到排名、分组 TopN 需求：用户积分排行榜、各部门薪资前三的员工、最近 N 个月的销售滚动统计……MySQL 8.0 引入的窗口函数让你用一条 SQL 就能干净利落地完成这些操作，不需要再写晦涩的自连接或用户变量。 本文通过用户积分排名和部门薪资 Top3 两个生产级场景，给出可直接运行的示例，并对比传统 GROUP BY + 子查询 方案的性能差异，帮助你在项目中快速落地窗口函数。 1. 环境准备123456789101112131415161718192021222324252627-- 验证环境：MySQL 8.0.35，InnoDB引擎CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, points INT NOT NULL DEFAULT 0) ENGINE=InnoDB;INSERT INTO users (name, points) VALUES('Alice ...

MySQL死锁问题排查与解决方案实战 真实场景：支付系统进行一笔退款操作时，后台日志赫然出现 Deadlock found when trying to get lock; try restarting transaction。退款失败，订单状态卡住，客服电话被打爆。作为后端开发，你能否快速定位死锁并拿出高可用方案？本文将通过 3 个完整可运行的案例，带你从死锁“现象”走到“根因”，再到“代码级修复”，并给出可落地的预防策略。 一、死锁是怎么发生的？在 MySQL InnoDB 引擎中，死锁是并发事务相互持有对方需要的锁，形成循环等待而无法继续执行的僵局。要打破死锁，必须先理解 InnoDB 的锁机制。 发生死锁的四个必要条件（缺一不可）： 互斥：资源只能被一个事务独占。 持有并等待：事务已持有一部分锁，同时在等待其他锁。 不可抢占：已获取的锁不能被外界强制释放。 循环等待：事务间形成首尾相连的等待环。 InnoDB 会自动检测死锁，并选择回滚代价最小的事务（undo log 较小的那个）来打破死锁，同时将死锁信息记录到 SHOW ENGINE INNODB STATUS 中。 ...

MySQL深分页查询性能优化实战想象一个场景：订单表里有上百万条数据，业务需要按创建时间倒序分页展示。前几页秒出，翻到第 1000 页时，SQL 却卡了 5 秒。这就是典型的深分页问题——当 OFFSET 变大时，查询性能急剧下降。 本文从真实业务场景出发，用可复现的示例带你定位问题，再给出 3 种实用的优化方案，所有 SQL 都能直接在你本地 MySQL 8.0 上运行。 1. 复现问题：200 万订单的深分页1.1 建表与造数据1234567891011121314151617181920212223242526272829303132-- 订单表，自增主键 + 创建时间索引CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, created ...

MySQL大表DDL操作风险与在线变更实战凌晨两点，DBA 小张被紧急告警吵醒：订单表orders的status字段需要从TINYINT扩展为INT，当他在 2 亿行的表上执行ALTER TABLE之后，业务连接池瞬间打满，所有订单操作全部阻塞，最终靠重启数据库并回滚当天数据才恢复。事故报告里写满了 “锁表”、“主从延迟 20 分钟”、“数据不一致” 的字眼。 这不是杜撰的故障，而是每天都在发生的现实。本文将从一个真实的压测场景开始，展示原生 DDL 的问题，然后深入pt-online-schema-change与gh-ost的原理，手把手带你完成三次完整的在线变更演练——每个例子都可以在你的机器上复现。 1. 原生 DDL 到底有多可怕？我们先在测试环境复现一次原生 DDL 带来的伤害。接下来的脚本会创建一张包含 500 万行数据的表，同时用 sysbench 模拟持续读写，然后执行ALTER TABLE ... ADD COLUMN，再观察阻塞时间和复制延迟。 1.1 环境准备1234567891011121314151617181920212223242526272829303 ...

MyBatis ResultMap 吞行问题 你写了一对多关联查询，数据库中明明有 10 行数据，MyBatis 返回的列表却只有 3 条。剩下的 7 行去哪了？这就是经典的 ResultMap “吞行”问题。 现象：数据去哪了？假设你有一张订单表 t_order 和一张订单明细表 t_order_item，一个订单可以包含多个商品明细： 123456789101112-- 订单CREATE TABLE t_order ( id BIGINT PRIMARY KEY, order_no VARCHAR(32));-- 订单明细CREATE TABLE t_order_item ( id BIGINT PRIMARY KEY, order_id BIGINT, product_name VARCHAR(64)); 你写了一个 SQL 用 JOIN 关联查询： 123456789<select id="getOrders" resultMap="OrderResultMap"> SELECT ...

埃隆马斯克 - 放眼未来 无所畏惧

Doris物化视图Apache Doris 物化视图详解1. 概述物化视图是一种预计算和储存数据的机制，它通过将复杂查询预算结果以视图的形式保存，以提高进一步查询的性能。对于大数据分析场景，物化视图可以最大稍少进一步计算，为 BI 分析和报表运行提供支持。 Apache Doris 作为一个面向分布式数据库分析的 MPP 架构，支持为大规模数据进行实时分析和回馈。物化视图是它的一个重要特性，可用于提升查询性能。 2. Doris 中物化视图的特点 自动选择符合的物化视图：在执行查询时，Doris 会根据查询的 SQL 自动匹配适合的物化视图，无需手动指定。 增量更新与数据不一致性操作：物化视图通过增量更新保证高效性和实时性。 支持复杂查询的预算：对于带有积分和聚合操作的复杂查询，物化视图可以显著提高性能。 更简单的管理方式：通过一套简单的命令，创建和维护物化视图，构造操作涉及深。 3. 创建物化视图在 Doris 中，创建物化视图的基本语法如下： 12345CREATE MATERIALIZED VIEW mv_nameASSELECT <column_list>FROM ...

Closeable通常来说，Closeable接口的使用需要配合 try with resource，关闭时自动执行Closeable接口定义的 close 方法 如果没有实现这个接口，就无法使用 try with resource，且需要手动关闭资源

永不放弃——特朗普自述【笔记整理】 关注解决之道，而不要抱怨出现的问题。 你的生意做的越大，你的人生境界越高，那么你遭遇的困难也会越有挑战性。如果你有这样的思想准备，那么在遇到困难时自己的情绪波动就不会太大，也不会无谓地烦恼甚至积郁成疾。 如果你觉得一个人在苦苦打拼，那么你可以用这种积极的精神力量来鼓励自己，内在的信念往往是人们分出伯仲高下的隐性分水岭。失败者往往都会选择放弃。 如果你遇到需要让你投入更多时间的情形，你不妨尝试一下，让自己渐入佳境。你最后都会为自己每天的成就而感到惊讶。 有的时候，如果你把所有可能出现的问题都考虑到了之后，你就不妨可以去想象可能会出现什么好事了。 勇气意味着绝不放弃。背弃理想很容易，失败者往往就是缩手缩脚的。被打倒是一回事，而自暴自弃则是另一回事。一些看似平凡的人之所以能够创下丰功伟业，正是因为他们的百折不挠和永不放弃的精神。 海明威说过一句名言：“勇气就是优雅地面对压力。” 勇气还有另一个好处，那就是能够帮助你用正确的思维来考虑问题和做出行动，它会让你关注面前的机遇，而非障碍。其实，很多问题换个角度去考虑就是机遇，只不过它的表现形式让我们 ...