一事不执，万事不全

引言：INT的“魔法数字”世界在MySQL里，INT是存储整数的“超级英雄”，但它身后跟着的括号（比如INT(11)）、ZEROFILL和UNSIGNED关键字却让不少人摸不着头脑。括号里的数字到底是干嘛的？ZEROFILL为啥要把数字前面塞满0？UNSIGNED又是个啥？别急！本文会用可爱又生动的语言，搭配一堆示例和表格，带你把这些“魔法”弄得清清楚楚！ 1. 括号里的数字：显示宽度or存储范围？当你定义一个MySQL表时，可能会看到这样的代码： 1234CREATE TABLE users ( id INT, age INT(2)); INT后面那个(2)是啥意思？很多小伙伴以为它限制了数字的大小，比如INT(2)只能存2位数（0到99）。但真相是：括号里的数字只影响显示宽度，不影响存储范围！ 1.1 显示宽度是啥？显示宽度（M）告诉MySQL在某些情况下（比如配合ZEROFILL）如何“美化”数字的显示。它不限制能存多大的数字，INT的存储范围永远由它的类型决定： 有符号INT（默认）：-2,147,483,648 到 2,147,483,647（32位，4...

一、引言在数据库的并发事务处理中，数据一致性和隔离性是至关重要的。MySQL作为广泛使用的关系型数据库管理系统，通过不同的事务隔离级别来平衡数据一致性与并发性能。其中，不可重复读（Non-Repeatable Read）和幻读（Phantom Read）是两种常见的并发问题，它们对数据的一致性构成了挑战。本文将深入探讨这两种问题的概念、产生原因，以及针对幻读问题的解决方法。 二、不可重复读与幻读的概念1. 不可重复读（Non-Repeatable Read）不可重复读发生在一个事务在两次读取同一数据时，由于其他事务的修改或删除操作，导致两次读取的结果不一致。这种情况通常出现在“读已提交”（Read Committed）隔离级别下。 示例： 123456789101112-- 事务ASTART TRANSACTION;SELECT balance FROM account WHERE id = 1; -- 第一次读取，结果为100-- 事务BSTART TRANSACTION;UPDATE account SET balance = 150 WHERE id = 1;COMMIT;...

在MySQL的InnoDB存储引擎中，B+树作为核心数据结构支撑着索引系统。理解其存储容量对于数据库设计和性能优化至关重要。本文将通过结构解析和数学推导，揭示三层B+树在典型配置下的数据承载能力。 一、B+树结构特性B+树由根节点、内部节点和叶子节点构成三层结构： 根节点：索引入口点，存储指向内部节点的指针 内部节点：作为路由层，存储键值和子节点指针 叶子节点：最终数据容器，存储实际数据记录或主键指针 每个节点大小由InnoDB页大小决定，默认配置为16KB（16384字节）。这种分层结构通过减少磁盘I/O次数实现高效查询。 二、存储容量计算公式数据存储量计算公式：总记录数 ≈ (每页指针数)^(树高度-1) × 每叶子页记录数 1. 内部节点指针数计算假设主键为BIGINT类型（8字节），指针占6字节： 12345每页指针数 = 页面大小 / (键值大小 + 指针大小) = 16384 / (8 + 6) ≈ 1170 个指针/页 2. 叶子节点记录数计算假设单条记录1KB： 12345每页记录数 = 页面大小 / 单条记录大...

在SQL查询中，JOIN操作是多表关联的核心工具，而条件的使用位置（ON vs WHERE）直接影响查询结果和性能。本文从原理、场景和最佳实践三个方面总结JOIN条件的使用规则，帮助开发者精准控制查询逻辑。 一、ON与WHERE的本质区别 执行顺序 ON条件：在连接（JOIN）操作时立即生效，用于确定两表如何匹配，生成临时结果集。 WHERE条件：在连接完成后对结果集进行过滤，作用于最终数据。 对结果集的影响 INNER JOIN：ON和WHERE效果相同，均过滤未匹配记录。 LEFT JOIN/RIGHT JOIN： ON条件仅影响关联表的匹配，保留主表所有记录。 WHERE条件会过滤整个结果集，可能导致主表记录丢失（如外连接时）。 FULL OUTER JOIN：ON控制匹配逻辑，WHERE进一步筛选结果。 二、场景化条件使用规则 JOIN类型 条件放在ON中 条件放在WHERE中 INNER JOIN 正确：过滤未匹配记录 正确：效果同ON，但语义较弱 LEFT JOIN 正确：保留左表全部记录，右表按需匹配 风险：可能过...

“一条 SQL 的效率，决定了你的数据库寿命。” 在我们日常 Java 项目开发中，数据库性能常常是系统瓶颈之一。你有没有遇到过以下场景： 明明加了联合索引，查询还是慢？ 明明字段都在索引里，为啥还是回表？ 一条查询跑得飞快，一改条件就爬行？ 别急，也许你缺的不是 SQL，而是对“索引下推”（Index Condition Pushdown，简称 ICP）的正确理解。 今天我们就从一个简单的例子出发，把索引下推这个“细节杀手”掰开揉碎讲清楚。 🧠 索引下推（ICP）到底是啥？简单说，ICP 是 InnoDB 存储引擎的一种优化技术，它的目标只有一个： ✅ 在使用联合索引时，尽可能在索引遍历过程中判断 WHERE 条件，✅ 减少“回表”次数，提高查询效率。 📚 一句话解释什么是“回表”？当你使用的是联合索引，而查询的字段不都在索引里时，InnoDB 会： 先根据索引找到主键 → 再通过主键去主键索引里“回表”查出整行数据。 这就是“回表”。 如果索引能“干掉”大部分无用数据，就不用回那么多表 —— 这正是 ICP 的厉害之处。 🧪 我们先来搭个实验场景1...

很多人在写 SQL 时，会混用 ON 和 WHERE 限制条件。但这并不是无关紧要的“风格”问题，尤其在 OUTER JOIN（如 LEFT JOIN）中，放错地方逻辑就彻底变了！ 1️⃣ 基础：ON 做“配对”，WHERE 做“筛选” ON 子句：定义两个表之间“如何配对”的逻辑。 WHERE 子句：在配对完成后对结果进行过滤，决定哪些行最终返回。 正如社区大佬所说： “The ON clause defines the relationship between the tables. The WHERE clause describes which rows you are interested in.” stackoverflow.com+14stackoverflow.com+14geeksforgeeks.org+14 2️⃣ INNER JOIN：语义一致，差距仅在“表达方式”对于 INNER JOIN（内连接），无论你把条件放在 ON 还是 WHERE，结果集最终都一样——这是数学上的布尔逻辑统一： 12345678910-- a) 条件放在 ONSELE...

“写得好的 SQL，懂得把条件说在前面。” 在日常 Java 开发中，我们常写各种复杂的 SQL：嵌套查询、视图、分页、聚合……而当查询语句一旦嵌套了子查询或视图，性能就可能扑街。 于是，一个非常重要的优化技术就显得格外关键：条件下推（Predicate Pushdown） 。 今天我们不说虚的，从实际例子出发，一口气把这招讲透！ 🧠 条件下推到底是啥？通俗地说： 条件下推是一种优化器层面的 SQL 优化策略，把原本在外层执行的 WHERE 条件，尽可能提前“下推”到子查询或视图中执行，这样能更早过滤无用数据，减少中间结果量，提高执行效率。 🌰 来个例子看不下推 vs 下推的区别表结构12345678sql复制编辑CREATE TABLE employees ( id INT PRIMARY KEY, name VARCHAR(50), department_id INT, salary INT); 我们写了个看似合理的 SQL 👇： 123456sql复制编辑SELECT * FROM ( SELECT * FROM employees WHERE...

亲爱的小伙伴们： 有没有过这样的经历？你明明把数据库更新了，可用户刷出来的页面还是老数据！这就好比你明明换了女友，朋友还在社交平台@你和前任的照片。🙃 这，就是Redis 缓存与 MySQL 数据库一致性问题——缓存，可能会“背叛”你！ 一、一致性种类，先分个类在正式讲缓存一致性之前，咱们得先整明白“一致性”到底分几种： 一致性类型 定义 举个栗子 强一致性 写入成功后，所有读请求立刻能读到最新值 银行转账、支付 弱一致性 写入成功后，读请求可能能读到最新值 一般业务场景 最终一致性 写入成功后，经过一段时间，读到的一定一致 微博点赞、浏览量、缓存系统 ✅ 关键认知： 强一致性 → 读写“实时一致” 最终一致性 → 短时间不一致可以接受，但最终肯定一致 二、Redis + MySQL 到底是什么一致性？答案是： 只能做到“最终一致性” 。 为什么？ MySQL：强一致（事务ACID保证） Redis：无事务、异步、非阻塞 → 快速但不保证一致性 Redis + MySQL：分布式异构系统 → 没有全局事务 → 只能靠“补救”保证最终一致 ✅...

“锁得住Redis的心，才锁得住并发的魂。” 在微服务、分布式、集群化的今天，如果你还在用 synchronized 对抗并发，那你就像拿着锁门的钥匙试图锁防盗门……根本锁不到点上！ 一、为什么需要 Redis 分布式锁？🔒 单体应用的锁，还行123synchronized (this) { // 线程安全了} ReentrantLock 也好，synchronized 也罢，它们都只在当前JVM进程里奏效。 🧨 分布式应用的锁，就不灵了假设你部署了两个实例在两台机器上： 时间 实例 A 实例 B T1 检查库存为 1，准备下单 - T2 - 也检查库存为 1，准备下单 T3 下单成功，库存变为 0 - T4 - 也下单成功，库存变成 -1 ❌ ❗ 这就尴尬了 —— 数据出现了“超卖”。 此时你需要一个能跨进程、跨JVM、所有实例可见的锁机制。 🎯 Redis 天生是分布式的，基于网络通信，天然跨 JVM，是锁的好载体。 二、Redis锁的实现原理（基础要讲透）📌 本质：用 SETNX + 过期时间 来模拟“...

——来自一位被死锁坑哭后发誓要掌控全局的程序员的灵魂写作 一、💣💣💣 为啥不用 RedisTemplate 来搞锁？你是不是也干过这种事儿： 1Boolean success = redisTemplate.opsForValue().setIfAbsent("lockKey", "anyVal", 10, TimeUnit.SECONDS); 再加上 delete("lockKey") 释放锁，看上去人畜无害、灵活轻便。但它有三个致命问题： ❌ 问题 1：线程挂了，锁永远不释放？忘记加过期时间，锁变成僵尸锁，谁都抢不走，业务直接卡死。 ❌ 问题 2：释放锁误删别人的锁！线程 A 加锁，过期前刚好线程 B 重复拿到锁，结果线程 A 还在 finally 里执行了 delete("lockKey") ——恭喜你，B 的锁被误删，相当于别人家刚换门锁，你拿着老钥匙又打开了！ ❌ 问题 3：没有重入性、没有阻塞等待、没有续期机制！你要想支持： 自动续期（像看门狗那样）❌ 阻塞等待...