数据库

一次真实的升级记录。 从 Ubuntu 默认 Cluster 管理模式，迁移到 PostgreSQL 官方推荐目录结构。 全程使用 pg_upgrade，保留所有数据库，最终实现： PostgreSQL 18 官方数据目录 systemd 管理 MacBook 远程访问 完整踩坑记录 一、为什么升级？ 原环境： 项目 版本 Ubuntu 24.04 PostgreSQL 16.14 数据目录 /srv/data/db/postgres/16/main 希望升级到： PostgreSQL 18.4 PostgreSQL 18 vs 16 关键改进 特性 PostgreSQL 16 PostgreSQL 18 增量备份 ❌ 仅全量 ✅ pg_basebackup 支持增量，备份时间减少 50%+ 逻辑复制 基础支持 ✅ 支持序列和大对象复制 并行查询 有限并行 ✅ 更多场景支持并行（VACUUM、CREATE INDEX） JSON 处理 JSONB 基础 ✅ JSON_TABLE 增强，复杂查询更高效 SSD 优化 无特殊处理 ✅ 强制 I/O 调度优化（见下文） 连接池 需外部工具 ✅ 内置连接池改进 SSD 专项优化（重要） PostgreSQL 18 对 NVMe/SSD 做了底层优化，这是升级的核心理由： ...

问题现象 普通 SQL 正常，stg 环境没发现异常。但生产环境用户反馈：超长 SQL（超过 1MB）会触发 400 报错。 恰好生产环境的用户有很多那种业务逻辑复杂、拼接出来的超长 SQL。 排查过程 第一步是对比。把报错的 SQL 和不报错的 SQL 摆在一起看，唯一的共同点就是——长。 短 SQL 跑得好好的，长到一定长度就 400。这不是 SQL 语法问题，是传输层的问题。 根因 查到最后，原因是这样的： 安全合规要求，把普通的 Statement 升级为 PreparedStatement。因为普通 Statement 有 SQL 注入风险，安全团队要求整改。 Presto 驱动版本太低，低版本的 Presto JDBC 驱动对 PreparedStatement 的支持不完善，特别是对超长 SQL 的处理有 bug。 服务端 Presto 没有同步升级。原因很简单——影响太大，涉及的下游服务和业务太多，不敢动。 所以就出现了一个尴尬的局面：客户端驱动升级了（为了安全），服务端没升级（为了稳定），两边版本不一致，超长 SQL 直接 400。 解决方案 还原升级。 把客户端驱动退回到兼容当前服务端的版本。安全问题用其他方式规避（比如在应用层做参数化查询、输入校验等）。 这不是最优解，但在"安全"和"可用"之间，先保可用。 避坑建议 1. 灰度环境重点覆盖验证 stg 环境为什么没发现？因为测试用的 SQL 都是短的。灰度环境应该重点覆盖边界场景： 超长 SQL（1MB+） 特殊字符 高并发场景 2. 客户端和服务端版本要对齐 升级驱动前，先确认服务端版本兼容性。不要客户端升了、服务端没升，两边版本不一致是定时炸弹。 3. 安全整改要评估影响面 ...

数据库选择 sqlite 小巧 无需安装 支持标准sql 语法 数据库客户端 DBeaver DBeaver (Community Edition) 支持 MySQL, PostgreSQL, SQLite等数据库 免费,开源 跨平台 DBeaver 下载安装 下载地址: https://dbeaver.io/download/ 创建示例数据库 下载jdbc驱动 打开sql脚本编辑器 DBeaver示例数据库-表介绍 DBeaver 默认自带的示例数据库 使用的是业界非常著名的 Chinook 数据库。 它模拟了一个 “数字音乐商店”（类似早期的 iTunes Store）的业务场景。 这个数据库结构非常经典，特别适合用来练习 SQL 的 JOIN（连接查询）、GROUP BY（分组统计） 以及理解主外键关系。 数据表 Album 音乐专辑表 Artist 艺术家/歌手 Customer 客户 Employee 员工 Genre 流派 Invoice 发票/订单头 InvoiceLine 发票明细/订单行 MediaType 媒体格式 Playlist 歌单 PlaylistTrack 歌单 sqlite_schema sqlite元数据 Track 歌曲/单曲 查看表关系 select 练习 1.select单表查询 select * from Track; 笔记: ...