有次运维群里收到报警：一台 8 核 16G 的服务 CPU 突然飙到 100%，持续 3 分钟没下来。 上去 top -H 一看，GC 线程没跑，业务线程没打满。占了 700% CPU 的是 tomcat 的 http-nio-8080-exec——就一个线程。 这就邪门了。一个请求，一个线程，吃的 CPU 顶得上 7 个核。 顺着线程 dump 看下去，热方法不是业务逻辑，不是数据库查询，是 com.fasterxml.jackson.core.json.UTF8JsonGenerator——Jackson 的序列化方法。 翻了一下接口参数：前端传了 pageSize=100000。数据库一条 SELECT * FROM order_history WHERE ... 跑出来 10 万行，MyBatis 映射完开始在 controller 里序列化成 JSON 写回 Response。 10 万条订单记录，每条约 80 个字段，序列化完 200MB 的 JSON。Jackson 在单线程里逐条序列化，边序列化边往内存里攒——CPU 不炸才怪。 一、全量序列化为什么这么耗CPU 很多....

导语 在现代应用开发中，灵活的数据存储需求越来越常见。传统的关系型数据库表结构难以应对频繁变化的业务需求，而 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()....

引言 最近在重构用户配置系统时遇到了一个经典问题：不同用户需要不同的配置字段，如果用传统的关系表设计，要么字段爆炸，要么频繁改表。后来发现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, -- 字体大小 -- ... 还有几十个可能的配置项 ....