服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 大促彩排当晚，秒杀压测到 3000 并发时，下单接口开始批量报错，日志里刷屏的是同一句话： Deadlock found when trying to get lock; try restarting transaction DBA 的第一反应是“死锁了，MySQL 会自动回滚一个，重启事务就行”——问题是这个死锁每秒都在发生：被回滚的那一半请求里，一部分重试成功，一部分又撞进下一轮死锁，订单创建成功率从 100% 跌到 62%，压测被迫中断。 更蹊跷的是业务视角的死锁描述：两个事务根本“没有”操作同一行——事务 A 更新的是 SKU 1001 的库存，事务 B 更新的是 SKU 2002 的库存，它们凭什么互相等待？带着这个“不相干的行为什么会死锁”的疑问，我们拉开了一次教科书级的 InnoDB 锁排查：SHOW ENGINE INNODB STATUS 的死锁日志 → lock_mode X locks gap 字样 → 真相是间隙锁。这篇文章完整还原排查过程，并附上死锁日志的逐行解读技巧。 一、30 秒补课：InnoDB 的锁到底有几种 看懂死锁日志的前提是分清锁类型。....

最近接触了几个面试，问到 "MySQL 怎么优化慢 SQL"，回答基本就一句话："加索引呗。" 再追问 "你怎么确定加哪个索引？Explain 的 type 字段有哪些取值？什么是 Using filesort？" 要么含糊其辞，要么干脆答不上来。 说实话，只会 EXPLAIN + SQL 然后盯着 key 字段看"有没有走索引"，这不算会用 Explain。Explain 输出的 12 个字段里藏着优化器的全部决策细节：SQL 先执行哪一部分、联合索引用了几个字段、排序走没走索引、临时表有没有产生——这些才是判断 SQL 性能瓶颈的关键。 今天这篇文章，把 Explain 的 12 个字段拆开来逐个讲，文末再放一道真实的 SQL 优化案例，带大家把学到的字段串起来用一遍。 一、执行计划长什么样？先有个整体印象 在任意一条 SELECT/UPDATE/DELETE/INSERT 语句前加上 EXPLAIN，MySQL 不会真的执行 SQL，而是返回优化器评估后的"执行计划"： EXPLAIN SELECT e.emp_name, d.dept_name FROM t_employe....

一、凌晨三点的告警 凌晨 03:15，手机突然震动。 【告警】服务 CPU 使用率达到 99.8% 实例：order-service-01 时间：2026-07-11 03:15:32 持续：已超过 5 分钟 我猛地从床上坐起来，打开笔记本电脑。凌晨三点，应该是定时任务在跑。登录到服务器，看到监控面板上 CPU 红线像心电图一样笔直。 问题已经发生了，现在需要冷静分析。 二、Arthas 排查：定位热线程 登录服务器，启动 Arthas： $ java -jar arthas-boot.jar * [1]: 12345 order-service.jar 选择进程 1，进入 Arthas 控制台。 2.1 dashboard：全局视图 $ dashboard ID NAME STATE %CPU TIME INTERRUPTED DAEMON 1 main RUNNABLE 0.0 0:01 false true 2 GC task thread#0 RUNNABLE 0.0 0:00 false true ... 25 pool-1-thread-1 BLOCKED 0.0 0....

一、问题背景：电商列表接口的性能瓶颈 某电商平台的商品列表接口响应时间突然从 100ms 飙升至 3 秒，用户体验急剧下降。排查发现： 慢查询日志：商品列表查询耗时超过 2.8 秒 EXPLAIN 分析：Extra 列显示 Using where; Using filesort 执行计划：虽然命中了索引，但存在大量回表操作 根因分析： 原始 SQL： SELECT id, name, price, category, status, created_at FROM products WHERE category = 'electronics' AND status = 1 ORDER BY created_at DESC LIMIT 10; 这条看似简单的查询存在两个严重问题： 回表查询：索引只包含 category 和 status，查询其他字段需要回到主键索引查找 文件排序：ORDER BY created_at 无法利用索引，导致额外的排序开销 二、核心概念：理解覆盖索引与回表 2.1 索引结构与回表机制 InnoDB 索引结构示意: ┌───────────────....

公司的后台管理有一个搜索功能，搜订单备注里的关键词。刚开始数据量小，MySQL 的 LIKE '%keyword%' 还能跑。后来订单涨到几百万条，一个模糊搜索要跑 8 秒。更倒霉的是，这个搜索请求直接打在主库上——索引走不了，全表扫描，CPU 飙到 90%，其他正常业务也跟着慢。 LIKE '%xxx%' 是数据库的噩梦。前导通配符导致索引完全失效，只能全表扫描。MySQL 虽然也有 FULLTEXT 索引，但中文分词烂、不支持复杂排序、而且仍然在主库上消耗资源。 今天聊聊怎么用 Canal 把 MySQL 的数据实时同步到 Elasticsearch，把搜索的活从主库彻底拆出来。 架构：主库只管写，搜索交给 ES MySQL（主库） Elasticsearch │ │ │ INSERT/UPDATE/DELETE │ ├──── Canal 监听 binlog ──────────→├─ 增量同步 │ │ │ 业务读写 │ 全文搜索 │ （走主库） │ （走 ES） Canal 伪装成 MySQL 的 Slave，订阅 binlog 的变更事件。任何 INSERT、UPDAT....

做分页功能的同学肯定都遇到过这个问题：项目初期数据量小，分页查询秒级响应，产品经理说加上分页功能吧，很简单。结果上线后数据量上来，第 100 页就开始慢了，到第 10000 页直接超时。 我之前就遇到过这样一个案例：一个订单查询系统，用户反馈查第 1000 页以后的数据要 30 秒+，根本没法用。排查后发现，后端用的就是最常见的 LIMIT 10000, 20。 今天我们就来聊聊深分页的性能问题，以及如何用 Search After 和游标机制让第 100 万页也能毫秒响应。 深分页的性能问题根源 1. 传统分页的致命缺陷 很多开发者用的分页方式是这样的： -- MySQL SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000, 20; -- Elasticsearch GET /orders/_search { "from": 10000, "size": 20, "sort": [{ "create_time": "desc" }] } 这种方式在小数据量时没问题，但数据量上来后就是灾难： 问题场景：1000万数据，....

做过数据库优化的同学肯定都遇到过这个问题：明明在字段上建了索引，查询却还是全表扫描。排查后发现，原来是 SQL 语句中用字符串类型去查询数字类型字段，触发了 MySQL 的隐式类型转换，导致索引失效。 我之前就遇到过这样一个案例：一个订单查询接口，明明 order_id 字段上建了索引，但查询时却用了 order_id = '12345' 这样的字符串条件。结果查询从毫秒级变成了秒级，线上出现大量超时。 今天我们就来聊聊 MySQL 隐式类型转换的陷阱，以及如何用 MyBatis 类型处理器来强制校正。 隐式类型转换的本质 1. 什么是隐式类型转换 隐式类型转换场景： 表结构： CREATE TABLE orders ( id INT PRIMARY KEY, order_id BIGINT INDEX, -- 数字类型，有索引 user_id INT ); 查询语句： -- 字符串查询数字字段 SELECT * FROM orders WHERE order_id = '12345'; -- 数字查询字符串字段 SELECT * FROM orders WHERE user_name....

在处理海量数据时，分页查询是一个非常常见的需求。然而，当数据量达到百万级甚至千万级时，传统的 LIMIT OFFSET 分页方式会变得越来越慢，尤其是在访问后面的页码时。 第 1 页：很快 第 100 页：有点慢 第 10000 页：非常慢 第 100 万页：几乎无法响应 今天，我们来探讨如何通过**游标分页（Keyset Pagination）**技术，让深分页查询变得飞快。 问题背景 LIMIT OFFSET 的性能问题 -- 查询第 1000000 页，每页 10 条 SELECT id, name, amount, create_time FROM orders ORDER BY create_time DESC, id DESC LIMIT 10 OFFSET 9999990; 执行过程分析： ┌─────────────────────────────────────────────────────────────┐ │ LIMIT OFFSET 执行过程： │ │ │ │ 1. MySQL 需要扫描前 10000000 条记录 │ │ 2. 然后跳过前 999999....

在数据库优化中，排序操作是最常见的性能瓶颈之一。当你的 SQL 查询包含 ORDER BY、GROUP BY、DISTINCT 等操作时，如果没有合适的索引，MySQL 可能会产生 Using temporary 和 Using filesort，导致查询性能急剧下降。 问题背景 假设我们有一个电商订单表，需要查询"2024年1月上海地区用户的订单列表，按订单金额降序排列"： SELECT o.order_id, o.user_id, o.amount, o.create_time, u.username, u.phone, s.shop_name FROM orders o JOIN users u ON o.user_id = u.user_id JOIN shops s ON o.shop_id = s.shop_id WHERE o.create_time >= '2024-01-01' AND o.create_time < '2024-02-01' AND u.city = '上海' ORDER BY o.amount DESC LIMIT 100; 执行结果....

一、自增主键耗尽的痛点 上个月，一位做电商的朋友遇到了一个棘手的问题：他们的订单表突然无法插入新数据，报错 "Duplicate entry '2147483647' for key 'PRIMARY'"。 "我们的订单表用的是 INT 类型的自增主键，"朋友无奈地说，"现在已经达到了 INT 的最大值 2147483647，无法再插入新订单了。" 我帮他检查了一下数据库，发现问题确实如此： 订单表的主键是 id INT AUTO_INCREMENT 当前最大 ID 已经接近 2147483647 系统每天新增约 10 万条订单 按照这个速度，最多只能再支撑 20 天左右 更糟糕的是，他们之前完全没有意识到这个问题，直到系统崩溃才发现。这种情况下，数据迁移和表结构修改的风险非常高，可能会导致服务中断和数据丢失。 二、传统方案的局限性 为了避免自增主键耗尽的问题，我们通常会使用以下方案： 1. 定期手动检查 -- 检查当前最大 ID 和使用百分比 SELECT TABLE_NAME, AUTO_INCREMENT, (AUTO_INCREMENT / POW(2, 31)) * 10....

前言 在数据库应用中，索引是提高查询性能的关键。然而，即使创建了索引，在某些情况下索引也可能会失效，导致查询性能下降。索引失效是数据库性能问题的常见原因之一，特别是在大型应用中。 想象一下这样的场景：你的应用在生产环境中突然出现性能瓶颈，响应时间变长，数据库服务器CPU使用率飙升。通过查看慢查询日志，你发现有大量的慢查询语句。进一步分析这些慢查询，你发现它们本应该使用索引，但实际上却没有使用，导致了全表扫描。 如何快速识别和解决索引失效问题？ 本文将详细介绍如何在 Spring Boot 中实现 MySQL 索引失效监控和执行计划分析，帮助你自动识别慢查询中索引未命中的原因。 一、核心概念 1.1 索引的工作原理 索引是一种数据结构，用于快速查找数据库表中的数据。在 MySQL 中，最常用的索引类型是 B+ 树索引。B+ 树是一种平衡树结构，它允许在 O(log n) 的时间复杂度内进行查找、插入和删除操作。 1.2 索引失效的原因 索引失效是指查询语句本应该使用索引，但实际上却没有使用，导致了全表扫描。常见的索引失效原因包括： 索引列参与计算：当索引列参与计算时，索引会失效 索引列....

导语 在现代应用开发中，灵活的数据存储需求越来越常见。传统的关系型数据库表结构难以应对频繁变化的业务需求，而 NoSQL 数据库虽然灵活但缺乏事务支持。MySQL 5.7+ 引入的 JSON 字段类型为我们提供了一种折中的解决方案，既保持了关系型数据库的可靠性，又获得了 NoSQL 的灵活性。 然而，JSON 字段的查询性能一直是一个挑战。MySQL 8.0 引入的虚拟列索引技术为解决这个问题提供了可能，使得我们可以在 JSON 字段上创建索引，获得接近传统列的查询性能。 本文将介绍如何在 SpringBoot 应用中使用 MySQL JSON 字段和虚拟列索引，实现灵活存储配置的同时，不妥协查询性能。 一、MySQL JSON 字段的特性与优势 1.1 JSON 字段的基本特性 1. 数据类型 MySQL 5.7+ 支持原生 JSON 数据类型 自动验证 JSON 格式的有效性 提供丰富的 JSON 函数进行操作 2. 存储方式 采用二进制格式存储，更紧凑高效 支持快速访问 JSON 对象的特定元素 避免了传统文本存储的解析开销 3. 操作函数 JSON_EXTRACT()....

一、高并发注册的噩梦 公司APP正在做推广活动，用户注册量激增，每秒有上千个注册请求。问题也随之而来： 重复注册：同一个用户账号被注册了多次 数据不一致：用户表中有大量重复的邮箱和手机号 性能下降：注册接口的响应时间从100ms飙升到了500ms以上 数据库压力：MySQL的CPU使用率居高不下 已经在代码里做了查重逻辑，但高并发下还是会出现重复注册。"这样的场景，作为后端开发的你，是不是也遇到过？ 二、传统方案的局限性 为了防止重复注册，我们通常会使用以下方案： 1. 查询后插入 // 1. 先查询用户是否存在User existUser = userRepository.findByUsername(username);if (existUser != null) { throw new RuntimeException("用户名已存在");}// 2. 如果不存在，则插入新用户User newUser = new User();newUser.setUsername(username);userRepository.save(newUser); 这种方案的问题： 并发问题....