数据库

浏览该分类下的所有文章

PostgreSQL WAL堆积排查实战

PostgreSQL业务表增长不明显,磁盘却可能被持续保留的WAL占满。本文从复制槽、归档失败与检查点机制切入,解释max_wal_size为何不是硬上限,区分restart_lsn与confirmed_flush_lsn,并提供只读诊断SQL。结合WAL生成速率、磁盘净增长和复制槽剩余预算,建立容量与恢复时间评估方法,说明删除WAL、盲目清槽和频繁检查点的风险,形成从定位、止血到验证的排障闭环。

PostgreSQL 18底层性能变革解读

PostgreSQL 18 的性能优化不再局限于加索引或调 SQL,而是从底层重构数据访问与建模方式。其异步 I/O 子系统通过 worker 或 io_uring 并发读取,显著改善大表扫描、Bitmap Heap Scan 和 VACUUM 的吞吐;B-Tree Skip Scan 允许联合索引在缺失最左列时仍能部分利用;原生 UUIDv7 提供时间有序标识,提升索引写入局部性;虚拟生成列将确定性行内计算统一到数据库;增强的 RETURNING OLD/NEW 可一次获取修改前后数据。文章强调,这些能力并非自动加速所有查询,升级前应基于真实负载测试,合理配置 I/O 并发参数,并关注统计信息恢复与生态兼容。

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

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

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

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

使用Spring Boot整合Mybatis-Plus实现数据库的增删查改

文章详细演示了在 Spring Boot 项目中使用 Mybatis‑Plus 完成增删改查的全过程。首先在 MySQL 中创建 `tbl_employee` 表并插入示例数据;随后初始化 Spring Boot 项目并在 `pom.xml` 中加入 Mybatis‑Plus、MySQL、Druid 等依赖。将数据库连接配置写入 `application.yml`,使用 Lombok 编写实体类并通过 `@TableName`、`@TableId`、`@Version` 注解映射表结构。定义继承 `BaseMapper` 的 Mapper 接口并在启动类上使用 `@MapperScan` 指定扫描路径。最后提供 JUnit 测试代码,分别演示 `selectList`、`insert`、`update`、`delete` 等 CRUD 操作的使用方法,验证 Mybatis‑Plus 与 Spring Boot 的无缝集成。

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

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

SQL

本文系统介绍了MySQL常用SQL技术要点:分页通过LIMIT实现并给出大偏移优化方案;聚合函数COUNT、AVG、SUM、MAX、MIN的作用及与GROUP BY配合使用;表关联包括内连接、左/右外连接及多对多、自关联的实现方式;外连接的概念及MySQL不支持FULL;行转列可用CASE/IF配合聚合实现;阐述SQL注入原理及防御措施(参数校验、预编译);演示关联更新语法;对比WHERE和HAVING的作用时机与性能差异。

索引

MySQL 索引是存放在磁盘上的独立结构,通过指针快速定位符合条件的行,主要有 BTREE 与 HASH 两种实现,MyISAM 只支持 BTREE,MEMORY 可用两者。索引分为普通、唯一、主键、单列、组合、全文、空间等类型,创建方式包括在 CREATE TABLE、ALTER TABLE 或 CREATE INDEX 语句。是否建索引应依据唯一性、查询、排序、分组等需求,并遵循最左前缀原则;并非所有列都适合建索引,频繁更新、低基数或不在 WHERE 中使用的列不宜建。索引能加速查询、保证唯一性、优化连接与排序,但会占用磁盘、增加维护成本。InnoDB 使用聚簇索引(主键即数据)和辅助索引(存主键指针),MyISAM 仅保存记录地址。B+树因高度低、支持范围查询而为主流,Hash 仅适合等值查询且易失效。索引失效常因函数、类型转换、LIKE 前缀或不满足最左前缀导致,可通过 EXPLAIN 检查并在必要时重建。

其他(数据库)

介绍了关系数据库的三大范式:1NF要求字段原子化,2NF消除非键属性对主键的部分依赖,3NF进一步消除传递依赖,满足3NF即可避免冗余。随后说明MySQL常用存储引擎InnoDB(事务、行锁、外键)和MyISAM(高插入/查询速度、无事务),以及其他引擎的基本特性。接着阐述redo log、undo log、binlog的作用:redo保障事务持久性,undo支持回滚和MVCC,binlog记录所有修改用于复制。进一步解释InnoDB的MVCC实现原理,包括隐藏列、undo版本链和ReadView。最后说明MySQL主从复制流程:主库写入binlog→从库读取并写入relay log→SQL线程重放,实现异步数据同步。

深入理解Mysql锁与事务隔离级别

本文系统阐释了 MySQL 并发控制的核心机制,包括事务的 ACID 特性、脏读/脏写、不可重复读、幻读等并发问题,以及对应的四种事务隔离级别(READ‑UNCOMMITTED、READ‑COMMITTED、REPEATABLE‑READ、SERIALIZABLE)与 MVCC、间隙锁、Next‑Key 锁的实现原理。进一步比较了 MyISAM 的表锁与 InnoDB 的行锁、意向锁、共享/排他锁的行为差异,演示了不同隔离级别下的读写冲突和死锁情形,并提供了通过索引、锁粒度、系统状态变量等手段进行锁优化和死锁诊断的实用建议。

脏写、脏读、不可重复读和幻读

文章说明并发事务会产生脏写、脏读、不可重复读和幻读四类并发问题,并通过示例阐明其产生原因:未提交事务被其他事务读写导致数据回滚或结果不一致。随后介绍事务隔离机制和四种隔离级别(READ‑UNCOMMITTED、READ‑COMMITTED、REPEATABLE‑READ、SERIALIZABLE),说明各级别对上述现象的防护能力,并指出 MySQL 默认使用 REPEATABLE‑READ。