TranquilXuan

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，且需要手动关闭资源

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

SQL必知必会-读书笔记(十三)存储过程是什么存储过程（Stored Procedure） 是一组预编译的SQL语句，它们被存储在数据库中，可以像函数一样被调用。存储过程可以接受输入参数、输出参数，并且可以包含控制流语句（如条件判断、循环等）。存储过程的主要目的是提高数据库操作的效率和安全性，减少网络流量，并且可以封装复杂的业务逻辑。 优点 提高性能：存储过程在创建时会被编译并存储在数据库中，执行时不需要再次编译，提高了执行效率。 减少网络流量：客户端只需要发送存储过程的调用请求，而不需要发送大量的SQL语句，减少了网络传输的数据量。 封装业务逻辑：存储过程可以封装复杂的业务逻辑，使应用程序代码更加简洁。 提高安全性：通过授予用户对存储过程的执行权限，可以限制用户直接访问底层表，提高数据的安全性。 虽然实践中基本用不到存储过程，但是可以作为了解的一环 如何创建基本语法 123456789DELIMITER //CREATE PROCEDURE procedure_name (IN param1 datatype, OUT param2 datatype)BEGIN -- S ...

SQL必知必会-读书笔记(十二)关于更新和删除 使用 UPDATE 时，只需要写一个 SET 如果想要更快地删除，可以使用 TRUNCATE TABLE，因为该命令不记录数据的变动 关于视图是什么视图是虚拟的表，只包含使用时动态检索数据的查询。 关键点视图本身不能加索引，但视图内sql的执行有可能会走索引 我理解的视图更多地用于逻辑封装，提高可读性，在追求速度和效率的场景中，暂时不了解视图带来的优势 总结视图的优点 简化查询和提高可维护性：视图可以封装复杂的查询逻辑，使查询更简单和易于维护。 视图的缺点 可能增加性能开销：视图在每次查询时都会重新执行其定义的查询，可能导致额外的性能开销，特别是在涉及大量数据或复杂查询时。