- 博客(77)
- 收藏
- 关注
RSS订阅原创 Redis事务与MySQL事务有什么区别？一文分清
Redis 与 MySQL 事务机制大比对——同样叫“事务”，能力差距却非常大Redis：队列执行 + 不支持回滚MySQL：严格ACID + 支持回滚保障本文拆解命令执行流程，带你完整理解 Redis 事务原理Redis事务 ≠ MySQL事务。多命令批处理原子队列干净执行WATCH控制并发一致性不支持失败回滚而 MySQL 事务，则提供完整 ACID 属性与可靠回滚机制，适用于关键业务数据。Redis事务用于加速简单写操作MySQL事务用于数据安全业务逻辑。
2025-12-21 15:53:36
562
原创 Java 单例模式的五种实现：饿汉式、懒汉式、DCL、静态内部类、枚举单例
在 Java 面试中，单例模式几乎是必问内容。虽然看似简单，但不同实现方式的线程安全、性能以及是否能抵御反射与序列化攻击，都存在巨大的差异。这次，卷卷就来将单例模式常见的五种实现方式进行整理和对比，适合用于学习、复习以及面试答题。饿汉式太着急，懒汉式太磨叽，DCL 看着帅但少个 volatile 就寄；懒汉式直接加锁效率太低，每次获取实例都要锁一次。今天的脑细胞库存-1，知识储备+1，算是赚了。类加载时就创建单例对象，无需加锁，线程安全。实例非常轻量，或者确定一定会使用的单例场景。实例在第一次访问时创建。
2025-12-16 20:58:52
855
原创 嗯对，就这一篇，彻底搞懂Java的SPI机制
在日常开发中，我们经常听到SPI机制，特别是在JDBC、Dubbo、Spring Boot自动配置等场景中。但真正能把SPI讲清楚的人并不多。今天程序员卷卷狗带你从原理到示例，彻底理解SPI到底是什么、解决什么问题、为什么框架离不开它。SPI（Service Provider Interface）是一种“插件式扩展机制”，让框架在运行时自动发现、加载你提供的实现类，而不用修改框架源码。框架只提供接口，由你决定用什么实现。在框架设计阶段，框架根本不知道你希望使用哪种实现，例如：如果所有实现都写死在框架内部
2025-12-15 17:21:03
899
原创 为什么MySQL默认使用可重复读RR？深入解析binlog与隔离级别的关系
在面试MySQL事务隔离级别时，很多同学会背出四个级别：读未提交RU、读已提交RC、可重复读RR、可串行化Serializable。但是很少有人知道：为什么MySQL默认不是RC（读已提交），而是RR（可重复读）？更少人知道这背后与binlog的格式兼容性有直接关系。今天程序员卷卷狗就带你彻底搞懂这个问题，让你在面试中一招制胜。MySQL的主从复制依赖binlog。binlog主要有两种格式：早期MySQL大量使用statement格式，因为它：但是也因此带来了一个严重问题：如果主从在执行同一条SQL
2025-12-15 16:51:06
992
原创 布隆过滤器(BloomFilter)究竟是什么？一篇文章彻底讲清楚
布隆过滤器是一种高效、轻量、极具工程价值存在性判断黑名单过滤缓存穿透防护大规模去重请求拦截与风控如果你正在做分布式项目、高并发缓存、搜索系统、风控系统，布隆过滤器绝对是必备武器。因为在工程化层面，它能用最小的代价解决最常见的高并发问题，让你的系统更稳健、更高性能。
2025-12-02 22:10:26
654
原创 卷卷的算法顿悟日志｜链表篇：一道题都不用背，链表只有 4 个核心思想
不是难度不是代码不是模板链表考的是“你能不能用有限的 forward-only 信息流，维护全局结构”。链表 = 单向信息流上的局部状态调节。反转、交换、删除、合并、找环，全部靠合理的状态保存与指针推进完成。
2025-11-18 11:33:20
893
原创 MySQL binlog 三种格式（STATEMENT / ROW / MIXED）深度解析：主从复制与数据恢复必须弄懂的核心机制
STATEMENT 更轻但不安全，ROW 最安全但最大，MIXED 是折中策略。强一致用 ROW，一般业务用 MIXED，读多写少可考虑 STATEMENT。主从复制是否可靠数据恢复是否完整业务安全性是否有保障的关键设计点。
2025-11-17 21:00:00
1639
原创 MySQL 高可用方案：主从 + MHA + ProxySQL + PXC 的实战应用与架构思考
主从 → MHA → ProxySQL → PXC 是 MySQL 高可用从基础到巅峰的完整进化链。小系统用主从，大系统加 ProxySQL，核心系统用 PXC。掌握这套架构演进逻辑，你不仅能答面试，还能真正落地高可用设计。
2025-11-17 16:00:00
981
1
原创 MySQL 分库分表与分布式事务问题：从架构设计到落地实战（深入易懂版）
分库分表解决性能问题；分布式事务解决一致性问题；最终一致性 + 事件驱动是大多数业务的最佳方案；能避免跨库就避免，多用冗余、多用异步、多用消息。只要掌握这些思想，你就真正理解了分库分表的本质。
2025-11-17 11:35:16
820
原创 MySQL 优化器执行计划深度解读：EXPLAIN 的每个字段到底意味着什么？
type 决定访问方式，key 决定索引是否生效，rows 预估扫描量，Extra 揭示性能隐患。看懂 EXPLAIN，你就具备调优 SQL 的真正能力。
2025-11-16 22:30:00
979
原创 MySQL 锁机制详解：共享锁、排他锁、意向锁与死锁原理（深度 + 通俗易懂版）
共享锁负责读，排他锁负责写，意向锁负责协调，MVCC 负责提高并发，索引决定锁粒度，顺序访问与小事务避免死锁。理解这些，你对 MySQL 并发控制的理解将提升一个维度。
2025-11-16 18:30:00
974
原创 MySQL 主从延迟问题深度解析：常见原因与解决方案（强总结 + 易懂版）
大家好，我是程序员卷卷狗。在实际生产中，你会发现“主库很快，从库很慢”的情况时有发生。这就是我们常说的主从延迟（Replication Lag）。从库读到旧数据读写分离架构出现一致性问题故障切换（Failover）可能产生数据丢失风险很多团队做了读写分离，但对主从延迟完全不了解，线上一旦延迟暴涨，很容易踩坑。今天我带你从原理 → 成因 → 解决方案深度剖析，让你彻底理解延迟为什么产生，以及如何稳住它。主库多线程写 → 从库单线程重放 → 延迟自然产生。
2025-11-16 13:00:00
946
原创 MySQL 主从复制机制详解：binlog 与 relay log 流程
MySQL 主从复制不是“同步 SQL”，而是“同步顺序日志”。binlog 是源，relay log 是缓存，SQL 线程是播放器。整个系统依靠“三线程 + 两日志”稳定运行。
2025-11-16 08:51:46
1157
原创 MySQL 深分页优化：LIMIT 100000 的替代方案
大家好，我是程序员卷卷狗。在实际项目中，分页查询是最常见的 SQL 场景之一。看似普通的分页，却是 MySQL 性能下降最典型的原因之一。深分页会导致大量无效扫描，使数据库压力急剧上升，严重时甚至拖垮整个系统。理解 MySQL 深分页的本质，以及掌握高性能替代方案，是后端开发必须具备的能力。深分页的性能问题来自 MySQL 扫描机制本身，而不是 SQL 写得好坏。用主键分页替代 OFFSET用索引覆盖替代全表扫描用延迟关联减少回表次数用业务手段避免深分页。
2025-11-14 07:30:00
717
原创 MySQL 缓存机制与查询缓存的消亡史
大家好，我是程序员卷卷狗。MySQL 在 5.x 时代提供了一种名为Query Cache（查询缓存）的机制，很多人以为它能提升查询性能，但在高并发环境中它反而导致性能下降。最终 MySQL 在8.0 中彻底移除了查询缓存。一旦表有写入，所有相关缓存全部失效（高并发写场景完全不可用）存在全局锁，反而拖慢性能缓存粒度太粗，命中条件极其苛刻现代系统完全转向使用作为缓存体系。Query Cache 是理想主义设计，不适合互联网高并发场景，因此被 MySQL 官方永久删除。
2025-11-13 20:00:00
819
原创 MySQL JOIN 机制与多表查询优化：驱动表选择、连接算法与执行计划解析
大家好，我是程序员卷卷狗。JOIN 是业务中最常见的 SQL 操作之一，但也是最容易写“慢”的 SQL。驱动表选错导致扫描量激增；JOIN 条件未命中索引 → 全表扫描；结果集过大 → 触发临时表、文件排序；多表 JOIN 顺序不合理 → 优化器误判。JOIN 优化的核心本质就是一句话：减少参与 JOIN 的数据量。JOIN 是 SQL 中最复杂也最容易写痛点的部分，驱动表选择索引命中JOIN 条件写法Where 过滤顺序表数据量小表驱动大表，被驱动表靠索引。
2025-11-13 13:07:09
1200
原创 MySQL 索引失效的十大原因与优化方案
大家好，我是程序员卷卷狗。索引确实能大幅提升查询速度，但它也有严格的适用条件。如果 SQL 编写不当、类型不匹配、使用函数或范围查询，MySQL 优化器就可能放弃走索引。索引失效不是 MySQL 的错，而是写 SQL 的姿势不对。编号原因优化方案①未使用索引字段检查 WHERE 条件②函数/运算作用在列上去除函数或改写逻辑③隐式类型转换保持字段与参数类型一致④!= 或 <>改为范围匹配⑤使用默认值或重设计⑥改为 ‘xxx%’ 或全文索引⑦联合索引跳列。
2025-11-13 09:49:10
834
1
原创 MySQL 慢查询优化：从定位、分析到索引调优的完整流程
大家好，我是程序员卷卷狗。在业务量快速增长的系统中，数据库性能问题往往出现在：慢查询优化的本质：MySQL 内置了慢查询日志（slow_query_log），用于记录执行时间超过阈值的 SQL。（2）查看慢查询数量（3）查看慢日志内容三、第二步：分析慢查询日志使用官方或 Percona 工具进行日志聚合分析。输出指标：指标含义CountSQL 执行次数Exec time总耗时Lock time锁等待时间Rows sent返回行数Row
2025-11-12 23:00:00
704
原创 Explain 执行计划详解：SQL 性能瓶颈与索引命中分析
大家好，我是程序员卷卷狗。在 MySQL 中，SQL 的执行效率取决于优化器的决策。优化器会根据表结构、索引、统计信息，选择一条“最优路径”去执行查询。我们可以用EXPLAIN查看优化器选择的执行方案，SQL 是否使用索引；是否走全表扫描；哪个表先被连接；过滤行数预估是多少。EXPLAIN 是读懂 SQL 性能瓶颈的第一步。EXPLAIN是 SQL 优化的“放大镜”，它能揭示每条语句的执行细节与瓶颈所在。看 type 判路径，看 key 判命中，看 Extra 判代价。
2025-11-12 18:00:00
893
原创 死锁的本质：形成条件、检测机制与排查策略
大家好，我是程序员卷卷狗。在数据库并发控制中，锁是保护一致性的必要手段。但当多个事务互相等待对方释放锁时，就会进入一种永远无法继续执行的状态——这就是死锁（Deadlock）。一句话概括：死锁是“事务之间的相互等待”，没有任何一方能先释放资源。死锁的本质是循环等待资源。它不是“异常错误”，而是并发控制中的自然现象。真正重要的是——设计出能快速检测、自动回滚、尽量规避的事务逻辑。锁太多不一定死，但乱锁一定死。下一篇（第 15 篇），我将写——
2025-11-12 13:15:00
675
原创 锁机制详解：行锁、表锁、间隙锁、意向锁全解析
大家好，我是程序员卷卷狗。在高并发场景下，多个事务可能同时修改同一条数据。为了保证数据一致性，数据库必须对操作对象加锁。尽可能细粒度化，加锁范围越小，并发性能越高。表锁（粗粒度）行锁（细粒度）间隙锁 / 临键锁（防幻读）意向锁（多锁协调）接下来，我们从最底层的原理开始讲。两个事务互相等待对方释放锁，最终陷入僵局。锁类型粒度作用说明表锁粗整表控制MyISAM 常用行锁细单行控制高并发友好间隙锁区间防幻读REPEATABLE READ 特有临键锁组合。
2025-11-12 08:58:46
717
原创 MySQL 四种隔离级别：从脏读到幻读的全过程
大家好，我是程序员卷卷狗。在数据库中，同时运行多个事务是常态。如果事务之间完全不隔离，就会出现脏读、不可重复读、幻读等问题。不同的业务场景，对“性能与一致性”的要求不同。于是 SQL 标准定义了四种事务隔离级别，用来平衡两者。一句话概括：隔离级别 = 性能与一致性的权衡。四种隔离级别是事务控制的核心框架。隔离级别一致性并发性能常用场景最弱最高日志、临时统计中高Oracle 默认，OLTP 系统高较高MySQL 默认最强最低银行、结算场景。
2025-11-11 21:30:00
960
2
原创 MVCC 可重复读原理与快照版本机制
大家好，我是程序员卷卷狗。在数据库高并发环境下，如果每个事务都使用“加锁”的方式来保证隔离性，不仅会大幅降低性能，还可能出现死锁。于是 InnoDB 引入了MVCC（Multi-Version Concurrency Control，多版本并发控制）。它通过“版本链 + 快照”机制，让大多数读操作不加锁，也能保持一致性。一句话总结：MVCC 是一种“用时间换锁”的机制：让读操作看到事务开始时的数据快照，而不阻塞写操作。
2025-11-11 17:30:00
1346
原创 MySQL 事务原理：ACID 与 InnoDB 的实现机制
大家好，我是程序员卷卷狗。在数据库系统中，事务（Transaction）是保证数据可靠性的核心机制。它确保了——即使在系统崩溃、断电、并发冲突等极端情况下，数据库依然能保持数据的一致性。事务 = 一组要么全部成功，要么全部失败的操作。InnoDB 正是 MySQL 中负责实现事务的核心引擎。undo log→ 回滚与快照；redo log→ 崩溃恢复；binlog→ 主从同步；2PC→ 一致性保障。事务可靠性 = redo + undo + binlog + 2PC。
2025-11-11 12:45:00
1007
原创 索引优化策略：高效建索引的 7 条实战准则
大家好，我是程序员卷卷狗。很多初学者认为“多建几个索引就能让查询更快”，但实际上——索引既能提升性能，也能拖垮性能。索引占用磁盘空间、增加写入开销、影响缓存命中率。因此，索引优化的核心不是“多”，而是“准”。本文将总结 MySQL 实战中最有效的7 条建索引准则每条都有示例和背后逻辑。建索引前先看查询模式；评估区分度与访问频率；避免冗余索引与过宽索引；定期分析执行计划，持续调优。索引是用来减少扫描行数的，而不是装饰。下一篇（第 10 篇），我将写——
2025-11-11 08:20:51
1042
原创 联合索引的最左前缀原则与失效场景
大家好，我是程序员卷卷狗。我们都知道给字段建索引能提高查询速度，但很多时候，你明明建了索引，SQL 却依然走全表扫描。面试官问：“联合索引的最左前缀原则是什么？“为什么有时候用了 LIKE、OR、函数就失效了？联合索引的底层结构是有序的前缀匹配树。联合索引的本质是一棵按列顺序排列的有序 B+ 树。最左前缀原则，是优化器决定是否能使用索引的根规则。一句话记住：匹配从左开始，遇“断”即停。掌握这一原则，你不仅能解释索引失效的原因，还能主动在表设计和 SQL 编写中“避坑提速”。
2025-11-10 22:00:00
873
原创 覆盖索引与索引下推：Explain 执行计划中的 Using Index 是怎么来的
大家好，我是程序员卷卷狗。在用EXPLAINExtra 字段含义覆盖索引（Covering Index）索引下推（Index Condition Pushdown，ICP）但很多开发者只知道它们“说明走索引”，哪种情况能出现？具体加速了哪一步？和“回表”有什么关系？本篇就带你彻底搞清楚这两个优化机制的底层逻辑。当 SQL 查询所需的所有列都能从索引中直接获取，无需回表访问聚簇索引时，就叫覆盖索引。举例说明age INT,
2025-11-10 15:00:00
871
原创 聚簇索引与二级索引：一次查询要走几棵树？
大家好，我是程序员卷卷狗。在 InnoDB 中，所有表数据都存放在索引结构里。这意味着：MySQL 的表 ≈ 索引树。尤其是 InnoDB 默认使用聚簇索引（Clustered Index）存储数据，同时还可以为其他列建立二级索引（Secondary Index）。很多同学听说过“回表”，但不清楚——为什么要回表？到底查一次数据要走几棵树？今天我们把这个问题讲清楚。聚簇索引与二级索引的区别，决定了 InnoDB 在查询时是“一棵树”还是“两棵树”。
2025-11-10 10:45:37
568
原创 B+树索引详解：从数据页到叶子节点的索引结构图
大家好，我是程序员卷卷狗。无论你在面试中被问 MySQL、MongoDB 还是 PostgreSQL，只要聊到索引，B+ 树几乎都是绕不开的核心话题。为什么 MySQL 不用哈希表？为什么不是红黑树？为什么偏偏是 B+ 树？要回答这些问题，先要理解InnoDB 的数据页结构与磁盘访问逻辑。B+ 树是一种为“磁盘 IO 优化而生”的多路平衡查找树。优势说明多路分支，树高低IO 次数少，性能稳定数据存储在叶子节点范围查询高效叶子节点有序链表支持顺序遍历与排序非叶子节点仅存索引键。
2025-11-10 07:15:00
790
原创 CHAR、VARCHAR、TEXT 的差别与存储方式
大家好，我是程序员卷卷狗。在 MySQL 中，字符串类型的选择是设计表结构时的关键决策之一。同样是存储文本，为什么有的人用CHAR，有的人用VARCHAR，还有人选择TEXT？这并不只是“定长 vs 变长”的问题。空间占用；查询性能；是否能使用索引；是否支持内存临时表。掌握底层区别，才能真正写出“性能友好”的表结构。特性CHAR(n)VARCHAR(n)存储类型定长变长占用空间固定 n 字节（不足补空格）实际长度 + 1~2 字节长度信息最大长度255 字节。
2025-11-09 23:45:00
959
原创 MySQL 页结构与数据存储原理全解析》
大家好，我是程序员卷卷。我们平时写 SQL 时，看到的都是逻辑上的“表”“行”“列”，但在 InnoDB 的底层，这一切都以页（Page）为单位进行物理存储与管理。无论是索引查找、缓冲缓存、磁盘读写，最小单位都是“页”。这意味着：如果你真正理解了页的结构，就能从底层解释“为什么随机 IO 慢、为什么自增主键快、为什么行锁粒度能控制到单行”。页（Page）是磁盘与内存交互的最小单位；每页默认大小为16KB；
2025-11-09 20:45:00
988
原创 InnoDB 与 MyISAM 的底层区别与选择策略
MySQL 的核心灵活性之一就是可插拔式存储引擎（Storage Engine）。每个表可以选择不同的引擎，来决定底层的数据组织、索引结构与事务特性。但在实际项目中，几乎所有面试官都会问：“InnoDB 和 MyISAM 有什么区别？为什么 InnoDB 是默认引擎？因为它直接体现你是否真正理解数据库的事务、锁、恢复机制与索引存储方式。InnoDB 和 MyISAM 的区别，不仅是“事务 vs 非事务”，MyISAM：轻量快速，但不可靠；InnoDB：健壮安全，适合线上生产。
2025-11-09 17:15:00
974
原创 MySQL 架构总览：从连接器到执行器的完整链路
MySQL 的整体架构分为两层：Server 层 + 存储引擎层。Server 层：负责 SQL 解析、优化、执行计划等（不关心数据存储方式）。存储引擎层：负责数据的“落地”与“读取”（如 InnoDB、MyISAM、Memory）。Server 层懂“怎么查”，存储引擎懂“去哪查”。图解结构如下│ Server 层 ││ 连接器 | 查询缓存（8.0已移除） | 解析器 | 优化器 | 执行器 │││ 存储引擎层 │。
2025-11-09 13:01:32
1334
原创 Redis 高并发八股文：缓存穿透、击穿、雪崩与解决方案
Redis 的引入让系统能“抗流量、快响应”，但在高并发环境下，缓存失效或查询异常，会导致请求集中打到数据库，形成雪崩效应。穿透（Penetration）→ 查的 key 根本不存在；击穿（Breakdown）→ 热点 key 过期瞬间；雪崩（Avalanche）→ 大量 key 同时过期。一句话总结：缓存穿透是“查不到”；缓存击穿是“突然没了”；缓存雪崩是“一起没了”。“让热点留在 Redis，让数据库喘口气。但当缓存出现“穿、击、崩”时，再快的数据库都可能被拖垮。
2025-11-09 07:30:00
659
原创 Java 内存模型（JMM）与 volatile、synchronized 可见性原理
在多线程环境下，每个线程都有自己的工作内存（CPU缓存），而共享变量存放在主内存中。问题是：一个线程修改变量后，其他线程可能看不到最新值。CPU 缓存导致“可见性问题”；编译器和 CPU 指令优化导致“重排序问题”；缺乏同步导致“原子性问题”。于是，JVM 定义了Java 内存模型（Java Memory Model, JMM）用来规定多线程访问共享变量时的行为规范，什么时候写入主内存、什么时候刷新到工作内存、哪些操作是有序的。JMM是理解所有并发机制的理论根基。从。
2025-11-08 22:00:00
940
原创 JVM 内存结构与 GC 调优全景图
无论是大厂 Java 面试，还是线上服务排障，“内存溢出”“GC 卡顿”“堆外内存泄漏”几乎是必考主题。JVM 的运行时内存是 Java 性能的根基，对象从创建到销毁的生命周期；GC 垃圾回收的分区与触发机制；调优的关键参数和优化策略。理解 JVM 内存结构 = 掌握 Java 性能优化的钥匙。JVM 内存结构决定了 Java 程序的运行效率与稳定性。理解堆分代、GC 原理与调优策略，不仅能在面试中回答“GC 是怎么工作的”，
2025-11-08 19:15:00
1042
原创 ConcurrentLinkedQueue 与 CopyOnWriteArrayList：无锁并发容器原理
传统容器如ArrayListLinkedList在并发访问时需要加锁，而Vector虽然线程安全，但由于锁粒度大、阻塞严重，在高并发环境下性能低下。于是，JUC（）提供了一系列无锁（Lock-Free）容器依赖CAS（Compare-And-Swap）原子操作来保证线程安全。→ 无锁链表队列→ 写时复制列表这两者分别代表了：一类是基于CAS 的无锁并发结构一类是基于读写分离的快照思想。和是无锁并发编程前者体现了CAS + 链表 + 自旋的高并发入队出队；后者体现了。
2025-11-08 15:15:00
1042
原创 ThreadLocal 深入解析：线程副本机制与内存泄漏风险
在并发环境下，多个线程往往会共享同一个对象，如果这个对象是可变的，就会造成线程安全问题。加锁（保证共享资源同步）；不共享（每个线程维护自己的副本）。就属于第二种方式：它为每个线程创建独立的变量副本，实现线程隔离。保存线程独享的数据（如用户上下文、会话信息）；数据库连接（Connection）；SimpleDateFormat、NumberFormat 等非线程安全对象；Spring 事务的线程绑定。value = v;
2025-11-08 10:57:27
858
原创 Semaphore 信号量机制：限流与并发控制的经典实现
在高并发场景下，我们常常需要控制同一时间允许访问某个资源的线程数量同时最多 10 个线程访问数据库连接池；同时最多 3 个线程下载文件；请求接口做限流控制。这些场景都可以用Semaphore（信号量）来实现。Semaphore 通过“许可证（permit）”机制控制并发数量，线程在执行前必须先获取许可证，执行后释放许可证。它是 JUC 中基于实现的同步工具，用途类似“计数器型锁”，但比锁更灵活。参数含义permits可用许可证数量fair是否使用公平模式（FIFO）
2025-11-06 22:00:00
629
原创 Condition 接口与等待唤醒机制：对标 Object.wait/notify 的精准控制
在中，线程通信依赖于wait()notify()必须依附在同一个对象监视器上；不能精确唤醒指定线程；不支持多条件队列管理。为了解决这些问题，JDK5 引入了Condition 接口，配合使用，提供更灵活、更精确的等待/唤醒机制。Condition是的高级版，底层依托实现。Condition是 Java 并发通信的精细化工具，它将传统机制演进为多队列、可控、精确唤醒的模式。掌握Condition，你就理解了 AQS 内核中“线程通信”的真正原理，也是等组件的基础。
2025-11-06 19:00:00
977
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人