MySQL

浏览该分类下的所有文章

从一个消失的标签,到 1478 倍的写放大

起点只是评论区的「博主」标签不见了,往下追却牵出了写放大 1478 倍的 binlog、一页 42 MB 的留言配图、跨五层嵌套的孤儿数据,以及同一个问题在代码里的四种答案。本文按排查顺序记录十四次改动的根因与取舍,包括两次把测量工具的毛病错当成站点故障的判断失误。

Java项目该如何选择8.4LTS与9.7LTS

MySQL 8.0 已于 2026 年 4 月正式进入 EOL,大量仍运行在 8.0 上的 Java 项目需要重新规划数据库版本。与此同时,MySQL 9.7 已成为新的 LTS,因此升级问题不再只是“8.4 还是 9.x”。本文结合官方升级路径,从 MySQL 8.4 与 9.7 的选择、认证插件变化、Connector/J、TLS、Upgrade Checker、SQL 回归、备份和回滚等方面,给出一套适用于 Spring Boot 项目的实际迁移方案。对于存量系统,更稳妥的策略通常是先迁移到 8.4 LTS,在稳定运行后再根据生命周期决定是否继续升级 9.7 LTS。

MySQL元数据锁与Online DDL排障实战

MySQL 的 Online DDL 并不意味着完全无锁。即使使用 INSTANT 算法,加字段仍可能等待元数据锁,并把后续查询拖入排队,最终耗尽 Java 服务的共享连接池。本文以 MySQL 8.4 和 InnoDB 为例,通过多会话实验还原阻塞链,结合锁记录、sys 视图与事务信息定位根因,区分变更算法、元数据锁等待和连接获取超时,并给出取消变更、缩短事务、兼容发布与故障演练方法,帮助建立可观测、可中止、可验证的数据库发布流程。

MySQL锁等待与连接池排队排查实战

接口变慢,并不一定是SQL执行慢。连接池排队、连接持有时间过长、行锁竞争和未结束的事务,都可能让系统在CPU不高时出现明显卡顿。本文以Java、HikariCP和MySQL为例,通过可复现实验拆分连接获取、数据库访问和连接占用时间,并结合sys视图定位阻塞者与长事务。同时分析连接池扩容、超时配置和事务拆分的适用边界,建立从应用监控到数据库诊断的排查路径,帮助开发者避免盲目加索引、加连接或重启服务。

一个“搜不到”的问题,重构了整个搜索链路

博客搜索看似只是一次关键词查询,但真正可靠的搜索需要处理输入规范化、召回策略、排序逻辑、分页一致性、缓存隔离以及用户反馈等多个环节。本文记录一次真实的博客搜索重构过程:针对短关键词“AI”无法命中的问题,分析 MySQL 全文检索与模糊匹配叠加导致的召回缺陷,重新设计搜索契约,将字面匹配作为结果召回依据,全文检索作为排序辅助,同时完善 URL 编码、分页边界、空结果状态和自动化测试。通过这次改造,搜索功能从“偶尔能用”变成了一条行为明确、结果稳定、可持续演进的搜索链路。

AI评论审核背后的状态机与一致性设计

AI 评论审核真正的难点并不是调用大模型,而是如何让一个异步、不稳定、可重试的外部能力融入业务流程。本文以 Spring Boot 博客评论系统为例,介绍如何通过状态机、事务提交后回调、乐观锁式条件更新、失败分层重试、事务一致性和前端结果定位,构建可靠的 AI 评论审核链路。通过明确状态流转、防止过期任务覆盖人工操作、保证回复数据一致性,并完善用户侧反馈闭环,让 AI 功能从“能运行”提升到“可维护、可恢复、可上线”的工程化实现。

金叶炸金花

这不是一个在浏览器里随机发三张牌的演示页面,而是一套完整的多人在线游戏系统。它支持实时对战、房间管理、断线恢复、AI 机器人、积分流水、历史记录和管理后台,并围绕服务端权威、状态一致性、并发控制与隐私隔离进行了系统设计。

一次OOM排查实录

日志在运行时被硬截断,排查后发现是 Linux OOM Killer 将进程强制 kill,根因是 2 GB 服务器同时运行 3 个未限制堆大小的 Spring Boot 项目、MySQL 8.0 和监控组件,JVM 默认占用近 3 GB,MySQL 参数又消耗数百 MB,且没有 Swap 作为缓冲。通过为每个 JVM 设置‑Xms/‑Xmx(如 512 M、256 M),调小 MySQL 的 innodb_buffer_pool、max_connections、关闭 performance_schema 并添加 2 GB swap,内存使用降至安全范围,进程不再被 OOM Killer 杀死。经验教训是:小内存机器必须限制 JVM、精简 MySQL 配置并配置 swap,长期方案是迁移数据库或升级机器。

CentOS 7 安装 JDK 8、MySQL 8、Redis 6、Nginx保姆级教程

本文提供在 CentOS 7 上一步步安装 JDK 8、MySQL 8、Redis 6 与 Nginx 的完整指南。包括卸载旧 Java、使用 yum 安装 OpenJDK 并配置环境变量;添加阿里云和 MySQL 官方仓库、安装并启动 MySQL、开放 3306 端口;安装编译依赖后源码编译 Redis、编辑配置、创建 systemd 服务实现开机自启;通过 epel 安装 Nginx、设置开机启动、检查状态并放通 HTTP/HTTPS 防火墙端口。

MySQL 新增字段但 Java 实体未更新:全面解析与解决方案

MySQL 表新增字段但对应 Java 实体未同步,会导致 MyBatis 映射错误、数据丢失或 JPA 启动失败等异常,进而出现功能异常、数据不一致和排查困难。根本原因在于 ORM 映射未保持同步,往往是手动更新疏漏或误以为 ddl‑auto 能双向同步。解决思路分为三层:①紧急修复——根据报错快速在实体类、resultMap 或 @Column 中补全字段并重新部署;②流程规范——使用 Liquibase/Flyway 管理数据库版本,强制在同一次代码提交中同步 SQL 脚本和实体改动,禁用生产环境的 ddl‑auto=update;③辅助工具——利用 IDE 插件、MyBatis Generator 等自动生成代码,强化 Code Review。通过版本控制、CI/CD 自动迁移和团队规范,可根除数据库‑代码不同步导致的故障。

代码优化的部分实例

文章通过几个实际案例展示常见的代码优化手段。先用 String.format 代替“+”或 StringBuilder 拼接长字符串,提高可读性;再将普通 I/O 改为 BufferedInputStream/BufferedOutputStream 并使用缓冲区,显著提升文件读写性能;通过把循环中第二层集合转为 Map ,利用键直接查找,减少嵌套循环次数;强调使用完 ResultSet、PreparedStatement、Connection 等资源后必须按顺序关闭,防止泄漏;最后指出频繁创建数据库连接的开销,推荐使用 Druid、C3P0 等连接池来复用连接,提高并发和稳定性。整体强调简洁、可读、低耗资源的编程实践。

Explain详解与索引最佳实践

Explain是MySQL用于模拟优化器执行SQL、查看执行计划的工具,支持普通、EXPLAIN EXTENDED(提供优化后语句与filtered)和EXPLAIN PARTITIONS(显示访问分区)等变种。Explain输出的列包括id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra等,分别说明查询层次、查询类型、访问的表、访问方式(system、const、eq_ref、ref、range、index、ALL)、可用索引、实际使用的索引、索引字节长度、匹配列或常量、估计行数以及额外信息(Using index、Using where、Using temporary、Using filesort 等)。索引最佳实践包括:使用全值匹配、遵循最左前缀原则、避免在索引列上做函数或类型转换、将日期函数转为范围查询以利用索引、创建覆盖索引以消除回表、尽量避免全表扫描、临时表和文件排序。通过EXPLAIN检查并优化查询,可显著提升MySQL性能。