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

引言 "商品表要加扩展属性，每个品类的字段都不一样，手机有内存和屏幕、服装有尺码和颜色、食品有保质期——要不我们引入 MongoDB 吧？" 这句话在架构评审会上出现过无数次。听起来很合理：灵活结构、文档存储、不用改表。但真把 MongoDB 引进来之后，团队往往在第三个月开始还债：商品基础信息在 PG、扩展属性在 Mongo，下单事务跨两个库没法保证一致；报表要 JOIN 订单和商品属性，只能在应用层拼；运维多一套副本集、备份、监控，DBA 又是另一套技能栈。 "有半结构化数据"不等于"需要一个文档数据库"。PostgreSQL 的 JSONB 类型把"文档的灵活性"和"关系数据库的能力"合在了一个库里：JSON 可以存任意结构，同时享受强类型校验、GIN 任意键索引、标准 SQL 查询和真正的 ACID 事务——商品基础列和扩展 JSON 在同一行、同一事务、同一条 JOIN 语句里。这篇文章讲清 JSONB 的真实能力边界和五个落地场景，回答那个反复出现的问题：到底什么时候该用 JSONB 扛住，什么时候才真的需要 MongoDB。 一、先搞清楚：JSONB 到底是什么，和 M....

引言 从 MySQL 转 PostgreSQL 的团队，第一个月往往觉得"索引嘛，还不都是 B+ 树那一套"，直到在 SQL 里写下 WHERE tags @> ARRAY['新品'] 和 WHERE detail @> '{"city":"上海"}' 才发现：B-tree 对数组、JSONB、全文检索、几何范围这些条件根本无能为力——你可以给数组列建 B-tree，但它只索引整个数组字面值，永远不会为"数组包含某个元素"这类查询服务。 PostgreSQL 与 MySQL 在索引上最大的不同，是它把索引框架做成了可扩展的：不同的数据形态和查询模式，配不同物理结构的索引。这篇文章讲清生产中最常用的四类——B-tree（默认主力）、GIN（倒排，JSONB/数组/全文检索）、GiST（几何/模糊/最近邻）、BRIN（超大有序表的极简索引），每个都给建索引语句、匹配的查询操作符、EXPLAIN 验证方法，以及体积/写入代价的实测量级。选错索引类型时"明明建了索引却走全表扫"的困惑，看完这篇就没了。 一、先有全局观：四种索引解决四种不同的问题 索引物理结构直觉最擅长的查询典....

引言 表结构迁完了、数据也灌进去了，应用一连数据库，报错像连珠炮一样蹦出来：column "user_id" does not exist（明明字段就在那）、operator does not exist: integer = character varying（参数类型不对）、syntax error at or near "LIMIT"（LIMIT 两个参数写反了）……我们迁第一个服务时，300 多条 MyBatis SQL 在测试环境跑出了 70 多个语法错误，全部集中在同一批高频差异上。 MySQL 的哲学是"我尽量帮你跑"，PostgreSQL 的哲学是"写错了我就报错"。这篇不讲选型（那是上一篇《为什么迁移》的事），只解决迁移动手时的具体问题——把返工率最高的 10 个语法差异逐个列透：每一个都给 MySQL 写法、PG 写法、错误现场和修复，MyBatis 项目额外标注 XML 适配要点。建议直接收藏，迁移时对照逐条改。 差异 1：自增主键 AUTO_INCREMENT → IDENTITY（SERIAL 能用但不推荐） MySQL CREATE TABLE t_ord....

引言 "我们要不要把数据库从 MySQL 换成 PostgreSQL？"——这个问题在我们团队被反复问了三次：第一次是听说同行都在用 PG，第二次是要做向量检索，第三次是被一个复杂报表 SQL 折磨了一周之后。三次的答案不一样：第一次没迁（纯跟风没有痛点），第二次新业务直接选了 PG（pgvector），第三次核心库做了完整评估后只迁了分析库。 "要不要迁"从来不是技术优劣题，而是成本收益题。PG 确实有大量 MySQL 没有或更强的能力（JSONB、物化视图、PostGIS、扩展生态），但 MySQL 也有它的优势：运维人才多、主从复制简单、大厂云服务成熟、简单读写下性能稳定。盲目迁移的团队往往在第一个月就被"ON UPDATE 居然不自动更新时间戳""字符串不能隐式等于数字"这些差异绊倒。这篇文章回答两个问题：PG 到底强在哪（七个能力点逐项对比），以及动手前必须完成的五个评估，文末附一份可以直接贴在 wiki 上的 MySQL vs PG 语法差异速查表。 一、先给结论：什么情况值得迁 情况建议 标准 CRUD、单库 < 千万级、团队只会 MySQL、没有特殊需求....

引言 大促彩排当晚，秒杀压测到 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 的锁到底有几种 看懂死锁日志的前提是分清锁类型。....

在处理海量数据时，分页查询是一个非常常见的需求。然而，当数据量达到百万级甚至千万级时，传统的 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....

在分布式系统中，缓存是提升系统性能的关键组件。然而，一个被忽视的安全隐患正在悄然威胁着你的系统：缓存穿透。 查询一个根本不存在的数据，每次都穿透到数据库 数据库压力剧增，系统濒临崩溃 恶意攻击者利用这个漏洞，瞬间打垮你的服务 今天，我们来深入探讨如何通过布隆过滤器 + 异步预热的组合方案，彻底解决缓存穿透问题。 问题背景 什么是缓存穿透？ ┌─────────────────────────────────────────────────────────────┐ │ 正常请求流程： │ │ │ │ 请求 → Redis缓存（命中） → 返回数据 │ │ 请求 → Redis缓存（未命中） → 查询DB → 写入缓存 → 返回数据 │ │ │ │ 缓存穿透： │ │ │ │ 请求 → Redis缓存（未命中） → 查询DB（无数据） → 不写入缓存 │ │ ↑ 每次都查DB，DB压力倍增！ │ └─────────────────────────────────────────────────────────────┘ 穿透带来的危害 // 假设有这样一个查询接口 public ....

在数据库优化中，排序操作是最常见的性能瓶颈之一。当你的 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; 执行结果....

引言 最近在重构用户配置系统时遇到了一个经典问题：不同用户需要不同的配置字段，如果用传统的关系表设计，要么字段爆炸，要么频繁改表。后来发现MySQL 8.0的JSON字段配合函数索引简直是为这种场景量身定制的解决方案。 很多同学一听到JSON就想到MongoDB这些NoSQL数据库，但其实MySQL 8.0对JSON的支持已经相当成熟了。今天就来聊聊如何用SpringBoot结合MySQL JSON字段，既保持关系型数据库的优势，又能灵活处理半结构化数据。 传统方案的痛点 关系型表设计的局限 面对用户配置这种多变的数据结构，传统方案的问题： 字段爆炸： -- 用户配置表设计噩梦 CREATE TABLE user_config ( user_id BIGINT PRIMARY KEY, theme VARCHAR(50), -- 主题 language VARCHAR(20), -- 语言 notification BOOLEAN, -- 通知开关 auto_save BOOLEAN, -- 自动保存 font_size INT, -- 字体大小 -- ... 还有几十个可能的配置项 ....

引言 大家好，我是服务端技术精选的作者。最近项目数据库压力越来越大，单台MySQL已经扛不住了。传统的垂直分库方案改动太大，后来发现SpringBoot的读写分离配合动态数据源路由，可以在不改变业务代码的情况下，轻松实现主库写、从库读的架构升级。 很多同学一提到数据库扩展就想到分库分表，但其实读写分离是最简单有效的第一步。今天就来聊聊如何用SpringBoot实现智能的读写分离，让系统既能写又能读，还能自动处理故障切换。 为什么需要读写分离？ 单数据库的瓶颈 面对高并发场景，单数据库的问题： 写入瓶颈： 主库既要处理写请求，又要同步数据到从库 写入QPS达到几千就容易出现瓶颈 锁竞争严重，影响整体性能 读取瓶颈： 大量查询请求都打到主库 主库CPU和IO资源被读写混合消耗 查询复杂度高时影响写入性能 扩展困难： 垂直分库需要改造业务代码 水平分表复杂度高 数据一致性难以保证 核心架构设计 我们的读写分离架构： ┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ 应用层 │───▶│ 动态数据源路由 │....

在日常开发中，我们经常会遇到需要延迟执行任务的场景，比如订单超时取消、优惠券到期提醒、邮件定时发送、消息重试等。传统的做法可能是使用定时任务扫描数据库，但这种方式效率低下，特别是在高并发场景下。 Redis作为一个高性能的内存数据库，为我们提供了多种实现延时队列的方式。今天我就来详细介绍4种基于Redis的延时队列实现方式，并分析它们各自的优缺点和适用场景。 什么是延时队列？ 延时队列顾名思义，是指元素进入队列后，可以延时一定时间再被消费者取出执行。这与普通队列的区别在于，普通队列中的元素一旦入队就可以被立即消费，而延时队列中的元素需要等到指定时间后才能被消费。 为什么要使用Redis实现延时队列？ 使用Redis实现延时队列有几个显著优势： 高性能：Redis基于内存操作，读写速度极快 丰富的数据结构：支持String、Hash、List、Set、ZSet、Stream等多种数据结构 原子性操作：Redis的命令都是原子性的，保证了数据一致性 持久化支持：可以配置RDB和AOF持久化，防止数据丢失 4种实现方式详解 1. 基于Sorted Set的延时队列 这是最经典也是最常用的....

今天咱们聊聊一个在数据库运维中最常见也最头疼的问题：大表优化。 大表的"甜蜜负担" 在我们的日常开发和运维工作中，经常会遇到这样的场景： 订单表数据量突破千万，查询响应时间从几十毫秒变成几秒钟 日志表数据积累到亿级，连简单的COUNT查询都让数据库不堪重负 历史数据表占用大量存储空间，备份和恢复时间长达数小时 分页查询在深分页时性能急剧下降 当数据量达到百万、千万甚至亿级规模时，传统的SQL优化手段往往显得力不从心。今天我们就来聊聊MySQL大表优化的实战方案。 大表的判断标准 什么是大表？通常我们认为： 单表数据量超过500万行 表大小超过10GB 单次查询响应时间超过1秒 当然，这只是一个相对概念，具体还要看硬件配置和业务需求。 优化方案思路 今天我们要解决的，就是如何系统性地优化MySQL大表。 核心思路是： 分库分表：从物理层面拆分大表 索引优化：提升查询效率 查询优化：改进SQL语句和查询逻辑 架构优化：引入缓存、读写分离等 索引优化策略 1. 合理设计索引 -- 避免全表扫描，创建合适的索引 CREATE INDEX idx_order_status_time ....

今天咱们来聊聊Elasticsearch的生产实践，这可是很多公司在搜索功能上的"心头肉"。 ES生产环境的那些"坑" 在实际工作中，你是不是也遇到过这些问题： 搜索响应时间突然变慢，从几十毫秒变成几秒钟 内存占用飙升，服务器经常报警 集群偶尔出现脑裂，数据不一致 写入性能下降，索引速度跟不上数据增长 这些都是ES在生产环境中常见的问题。今天我就跟大家分享一些经过实战检验的最佳实践，帮你避开这些"坑"。 1. 索引设计：合理规划是成功的一半 索引设计就像盖房子的地基，地基不牢，地动山摇。在设计索引时，你需要考虑： 分片策略：分片数不是越多越好。通常建议每个节点不超过20-25个分片，过多的分片会增加集群管理开销。一个经验法则是：每GB堆内存对应20-25个分片。 副本设置：至少设置1个副本保证高可用，但在高写入场景下可以临时减少副本数，写入后再恢复。 映射优化：明确字段类型，避免动态映射。对于不需要搜索的字段，设置"index": false。 { "mappings": { "properties": { "title": { "type": "text", "analyzer"....

Redis作为分布式缓存的明星选手，确实为我们的系统提供了强大的性能支持。但在某些场景下，Redis反而成了性能的瓶颈： 网络延迟：每次访问Redis都需要经过网络请求，即使在内网，延迟也在1-2ms左右 序列化开销：对象需要序列化和反序列化，增加了CPU开销 连接池限制：Redis连接池有最大连接数限制，高并发下容易成为瓶颈 带宽限制：大量缓存访问可能占用网络带宽 今天，我们就来聊聊如何用Caffeine这个本地缓存神器，来解决Redis的性能瓶颈问题。

Elasticsearch不仅仅是一个搜索引擎，更是一个强大的数据分析平台。但要让它在生产环境中稳定运行，需要我们掌握一系列最佳实践。从集群架构设计到索引管理，从性能调优到安全防护，每一个环节都至关重要。今天我就把自己在生产实践中总结的Elasticsearch最佳实践分享出来，希望能帮你避开这些"坑"，让你的ES集群稳如泰山！