- 博客(706)
- 收藏
- 关注
RSS订阅原创 PostgreSQL实战笔记 | 结合PostgreSQL进行实时推荐与搜索
本文以生产级实时推荐与语义搜索服务为背景，完整演示基于PostgreSQL的向量搜索系统设计：从数据建模（物品表融合向量与全文索引）、异步向量生成、HNSW+部分索引优化，到搜索与推荐查询API的SQL级融合实现。强调PG作为唯一数据源的简洁架构，提出“缓存结果而非向量”的策略，并回答可扩展性与PG边界问题——当规模超限时，可逐步引入专用向量库，但初始阶段应坚持“用PG统一一致性”。
2026-11-07 18:45:09
429
原创 小鲸鱼交卷DSH v0.2.2-rc.1：811 个 commit，移动端、多语言、插件管理全面升级就位
DeepSeek Harness v0.2.2-rc.1 发布，汇聚811个提交，全面升级移动端适配、多语言支持（新增日语等六种语言）、聊天引用与历史导出、插件管理优化及四大实验性插件。重点包括工作树集成、代码审查支持、WebSocket压缩、Node.js最低版本升至24.9，显著提升跨平台体验与开发效率。
2026-11-07 09:30:00
729
原创 PostgreSQL实战笔记 | 向量检索算法与性能调优
调优维度核心旋钮/手段关键数字与原则诊断顺序先查执行计划，再分构建慢/查询慢Index Scan才是对的；说明索引被忽略HNSW查询（默认40）先满足召回目标（≥0.95），然后停手HNSW构建m（16）、（64）；过低则图质量永久受损IVFFlatlistsprobes（默认1）；是扫描比例过滤搜索0.8+的分水岭；默认20,000批量/并行合并SQL、work_mem减少往返；work_mem256MB+起步；连接池中用SET LOCAL高维halfvec、降维、量化2000维是vector。
2026-11-06 15:08:00
421
原创 PostgreSQL实战笔记 | 向量数据库与传统全文搜索的区别与结合
全文搜索与向量搜索的“漏”互补：前者精于关键词匹配，后者强于语义泛化。混合检索通过融合二者优势，提升召回率与精确度。PostgreSQL的全文搜索基于tsvector与GIN索引，需预计算以提升性能；向量搜索则依赖嵌入模型与ANN索引（如HNSW）。融合算法首选RRF，因其不依赖分数归一化、平等融合两路结果，实现简单且稳定。混合检索适用于兼具精确与语义查询的场景，但代价为延迟增加与实现复杂化。最终，选择应基于业务需求而非技术偏好。
2026-11-06 15:06:36
415
原创 PostgreSQL实战笔记 | pgvector索引的原理与应用场景
主题核心结论HNSW构建参数m（默认16，12–48合理，可降至4–8省内存）；（默认64，必须≥2×m，决定召回上限）；构建后固定，需重建才能改HNSW查询参数ef_search（默认40），查询时动态调；先满足召回目标，再停手IVFFlat参数lists（构建时，rows/1000起步，百万以上sqrt(rows)probes（默认1，起步）；是扫描比例构建时间HNSW重（CPU/内存密集，0.6.0+并行可大幅加速）；IVFFlat轻（K-means+一次扫描）；先灌数据后建索引是铁律。
2026-11-05 20:33:22
214
原创 PostgreSQL实战笔记 | 向量相似性搜索的概念与原理
本文深入解析向量检索中的核心算法——精确KNN、HNSW与IVF，揭示其在召回率与延迟间的权衡。精确搜索虽保真但效率低下，难以支撑大规模场景；HNSW通过分层图结构实现高速近似搜索，依赖ef_search动态调优；IVF则借鉴倒排思想，以聚类缩小搜索范围，由nprobe控制精度。二者各具优势：HNSW性能稳定、内存消耗高，适合查询密集型场景；IVF构建快、内存低，适用于可定期重建的静态数据。评估召回率应以Recall@K为基准，通常≥95%即满足业务需求。关键在于：先确保召回达标，再停止调参，避免无谓延迟增
2026-11-05 20:32:39
233
原创 【免费代码】双十一福利：送315套代码-无偿-无套路
095基于SpringBoot的游戏账号交易系统的设计与实现.zip。089基于SpringBoot的茶叶商城系统的设计与实现1.zip。090基于SpringBoot的茶叶商城系统的设计与实现2.zip。083基于JavaWeb的兼职发布平台的设计与实现.zip。100基于软件研发过程中的缺陷管理系统的设计与实现.zip。082基于JavaWeb的花店销售系统设计与实现.zip。099基于机器学习的商品智能推荐系统的设计与实现.zip。102基于推荐算法的智能书店的设计与实现.zip。
2026-11-05 20:26:38
687
原创 PostgreSQL实战笔记 | pgvector进行基本向量操作与查询实践
向量查询的核心挑战在于理解“ANN 索引返回有序列表而非集合”这一本质。选择距离算子需权衡语义与性能：归一化向量优先用 <#>（负内积），文本嵌入推荐 <=>（余弦）。索引仅在 ORDER BY + LIMIT 时生效，否则退化为全表扫描。混合查询中 WHERE 过滤可能导致召回暴跌，因候选集被过滤后不足。解决方案包括：使用 pgvector 0.8+ 的迭代扫描（relaxed_order）提升召回；对低基数过滤条件创建部分索引；或通过过采样+重排兜底。性能评估须兼顾延迟（EXPLAIN ANALYZE）
2026-11-04 20:36:12
437
原创 PostgreSQL实战笔记 | 向量化概念与应用场景
向量化将文本、图像等映射至高维坐标，实现语义相近则距离相近的搜索逻辑，突破传统关键词匹配局限。文本嵌入依赖模型维度与分块策略，图像嵌入通过多模态模型实现跨模态检索。语义搜索需融合向量与全文检索以兼顾语义与精确匹配。在RAG中，向量化承担语义检索，但整体质量取决于“上下文数据层”的完整性。PostgreSQL并非单纯向量库，而是整合向量、文本、元数据与全文索引的统一数据层，保障检索、过滤、权限与一致性的协同，尤其适合规模可控、上下文耦合强的场景。
2026-11-04 15:17:49
189
原创 PG实战笔记 | 45 PostgreSQL如何存储与管理向量数据？
本文深入探讨 pgvector 在生产环境中的向量数据管理核心问题：vector(n) 实际存储为 4n+8 字节，1536维向量每条约6.1KB，1亿条即超600GB；维度必须严格一致，建议使用 vector(n) 并通过“扩展/收缩”策略安全迁移；表结构应包含外键、过滤列与预计算 tsvector 以提升查询效率；批量导入须用 COPY + FORMAT BINARY 先灌数据后建索引；千万级向量需靠分区、降维、量化（如 halfvec）控制内存开销；备份时需提前安装扩展，索引建议恢复后重建。存储与索引
2026-11-03 12:01:33
319
原创 PG实战笔记 | 44 pgvector扩展安装与初步配置实践
本文详解在PostgreSQL中安装与使用pgvector的实操流程，涵盖五种安装方式（包管理器、Docker、Homebrew、源码编译、PGXN），重点揭示源码编译时需正确设置PG_CONFIG以避免路径冲突。强调扩展名应为vector而非pgvector，且需在每个数据库中单独创建。指出向量维度限制：存储上限可达16,000，但索引上限约2,000（vector类型），超维需用halfvec或降维。提醒建HNSW索引前需调大maintenance_work_mem，并注意跨机器编译时禁用-march=
2026-11-03 11:59:11
343
原创 PostgreSQL什么是向量数据与向量化表示？从“给事物编号”到“给事物定位”
向量化本质是将事物从“编号”转化为“空间中的位置”，使语义相似性可度量为几何距离。嵌入模型通过学习上下文共现规律，将语义关系编码为向量间的方向与距离，实现语义的几何化表达。维度并非越高越好——高维虽增强区分力，却带来维度灾难、计算成本上升与稀疏性问题。实践中应权衡表达力与效率，以实际检索效果为准。核心在于：让“像不像”变为“近不近”，这是向量技术的基石。
2026-11-02 22:27:01
329
原创 PostgreSQL 生态中支持 AI 的相关扩展概览：pgvector、PostGIS、TimescaleDB、Madlib、PL/Python 怎么选、怎么配合
向量检索选 pgvector，空间过滤选 PostGIS，时序数据选 TimescaleDB，库内机器学习选 Madlib，需要外部模型或 Python 生态选 PL/Python。
2026-11-02 22:23:44
439
原创 蔬菜种植知识库RAG--基于 RuoYi-AI 的蔬菜种植知识库 + 智能咨询系统
今天聊的这个项目「蔬智答 VeggieMind」，就是把这件事做成了现实。它基于 RuoYi-AI 改造，是一个面向菜农、家庭种植者和农技推广人员的「蔬菜种植知识库 + 智能咨询系统」，同时也是一个特别适合拿来做毕设、课设、作品集的 AI 应用范例。
2026-11-01 21:02:40
850
原创 为什么PostgreSQL适合AI场景？
问题结论AI 应用需要什么？向量检索、结构化过滤、多模态统一存储、事务一致性、混合检索，五者耦合PG 凭什么适合？扩展机制覆盖多模态；pgvector 让向量成为表的一列；事务一致性消除跨系统对账PG 的核心优势不是单个能力最强，而是“业务数据 + 向量 + 元数据”在同一个事务边界内PG 的真实短板HNSW 内存开销限制规模；向量能力是外挂而非内核原生；高并发写入和水平扩展有张力准确表述PG 适合“向量是功能之一”的 AI 应用；不适合“向量是唯一负载、十亿级、极端 P99”的场景。
2026-11-01 19:53:50
246
原创 PostgreSQL慢查询定位与优化
本文聚焦数据库性能优化闭环：发现、定位、优化、验证。强调应以“总执行成本”（total_exec_time）而非单次耗时为优化优先级。通过 pg_stat_statements 聚合分析资源消耗，结合慢查询日志与 auto_explain 深入执行计划，精准定位瓶颈。优化遵循三优先级：修复统计信息 → 重写SQL → 加索引，并以 EXPLAIN (ANALYZE, BUFFERS) 验证效果，确保优化真实有效。
2026-11-01 19:53:14
142
原创 PostgreSQL 性能瓶颈排查技巧：从操作系统到会话等待，找到那条“真正的慢”
PostgreSQL性能问题常源于操作系统资源瓶颈，而非数据库内部。排查应遵循“先看系统资源（CPU、内存、I/O）、再查当前会话等待、最后分析历史慢查询”的顺序。关键在于通过top、vmstat、iostat与pg_stat_activity的时间对齐分析，区分瓶颈来源。重点关注us/sy判断计算或内核开销，si/so识别真实内存压力，await和%util评估磁盘性能，锁等待则用pg_blocking_pids快速定位阻塞链。pg_stat_statements仅用于历史资源消耗分析，避免误判。
2026-10-31 21:39:00
230
原创 PostgreSQL 执行计划基础解读：看懂 EXPLAIN，找到那条慢 SQL 的真正瓶颈
执行计划是优化器对SQL执行路径的“预算表”，核心在于识别估算与实际差异大、累计耗时高、循环次数多或读盘频繁的节点。通过EXPLAIN ANALYZE结合BUFFERS和VERBOSE，可精准定位瓶颈：统计信息过期、列间相关性忽略或数据倾斜常导致估算失真，进而引发错误计划选择。应优先更新统计、创建多列统计或调整参数，而非盲目加索引。
2026-10-31 21:37:40
424
原创 PostgreSQL常见索引问题与解决方案
本文系统梳理了索引从创建到运维的全生命周期管理问题：通过执行计划分析索引失效的四大场景——隐式类型转换、函数包裹、统计信息过期与高选择率导致的优化器弃用；利用 pg_stat_user_indexes 识别未使用索引，强调删除前需验证业务依赖、避免误删；针对索引膨胀，推荐使用 REINDEX CONCURRENTLY 并结合 pgstatindex 评估密度；最后指出冗余索引的两类形态（完全重复与前缀重叠），提出基于元数据对比的检测与清理策略。核心理念：索引管理不仅是性能优化，更是降低写入开销、保障 aut
2026-10-30 15:29:59
227
原创 PostgreSQL索引优化策略
本文深入探讨索引优化的决策逻辑：基于选择性与基数判断索引有效性，复合索引列顺序应遵循“等值在前、范围在后”的查询模式原则，部分索引适用于高频偏斜查询，表达式索引解决函数包裹查询的索引失效问题，INCLUDE 可提升 Index Only Scan 效率但受 VACUUM 影响。通过五步流程（分析执行计划、识别查询模式、复用现有索引、设计合理索引、验证效果）精准建索引，并警惕索引过多带来的写放大、空间浪费与优化器负担，最终实现“知其所以然”的高效索引策略。
2026-10-30 15:29:17
400
原创 PostgreSQL 索引底层原理：B-tree、Hash、GiST、GIN、BRIN 到底怎么工作
PostgreSQL 索引并非单一结构，而是五类专为不同场景设计的工具：B-tree 通用高效，适合等值与范围查询；Hash 仅支持等值，查找更快但不支持唯一约束；GiST 处理空间与复杂关系，支持剪枝但需回表校验；GIN 专攻多值列（如数组、JSONB），适合“包含”类查询；BRIN 以极小代价概括物理有序的大表，适用于时序数据范围过滤。选错索引类型，比不建索引更糟。
2026-10-29 20:28:38
331
原创 PostgreSQL 死锁的诊断与处理：从 deadlock_timeout 到应用层加锁顺序
PostgreSQL死锁由互斥、持有等待等四条件引发，其检测依赖deadlock_timeout（默认1秒），超时后检查等待图并终止代价最小事务。应用层应通过统一加锁顺序（如ORDER BY id FOR UPDATE）、短事务、强锁优先、合理索引及有限重试来预防。日志定位需开启log_lock_waits与log_line_prefix，结合deadlock detected详情与pg_locks实时视图分析。核心原则：数据库负责“终止”，应用负责“避免”。
2026-10-29 20:25:18
350
原创 PostgreSQL咨询锁的使用
咨询锁是PostgreSQL中用于实现应用级互斥的机制，适用于行锁与表锁难以处理的场景，如分布式任务串行化。其核心在于“合作式”锁：由应用显式加锁、解锁，数据库仅保证同一锁ID的互斥性。分为会话锁（持有至释放或会话结束）和事务锁（自动随事务提交/回滚释放），前者适合长周期任务，后者更安全。锁ID可采用双键形式（命名空间+资源）避免冲突，提升可维护性。需注意LIMIT与锁函数顺序问题，避免锁泄漏。相比Redis分布式锁，咨询锁绑定于连接/事务生命周期，崩溃后自动释放，具备更强的故障安全性，但锁状态不复制，仅限
2026-10-28 21:30:42
402
原创 小鲸鱼DeepSeek Harness 最新进展：0.2.2发布，2161 个 commit，这次真的玩大了
两周内，DSH 从 v0.2.1-rc.1 快速迭代至 rc.4，并发布 v0.2.2-alpha.2，累计提交超2161次。版本聚焦模型适配、搜索能力升级、草稿修复与插件管理优化，新增多语言支持、聊天引用、历史导出及移动端体验改进，实验性功能全面铺开。新版大幅提升平台化能力，标志着 DSH 正从“能用”迈向“好用”。升级需注意 Node.js 版本（≥24.9）及 PTC 配置迁移。
2026-10-28 21:24:06
1128
原创 PostgreSQL表级锁、行级锁、轻量级锁
PostgreSQL 锁机制分表级、行级与轻量级锁三层，用户需掌握表级锁（如 ACCESS EXCLUSIVE 阻塞所有操作）与行级锁（锁行版本，仅阻塞写写）。关键在于：无索引的 UPDATE 会因全表扫描导致大量行被锁，等效“锁升级”。通过 pg_locks 与 pg_stat_activity 联合分析可定位阻塞源，终止长事务或死锁。避免锁问题的核心是：走索引、控事务大小、按一致顺序加锁，超时配置仅为兜底。
2026-10-27 11:22:07
359
原创 PostgreSQL事务隔离级别与案例
PostgreSQL 的隔离性实现超越标准：其 Repeatable Read 通过事务级快照避免幻读，而非依赖间隙锁；Serializable 借助 SSI 检测并回滚导致序列化异常的冲突，但需应用层重试。三者中，Read Committed 适合多数场景，Repeatable Read 提供稳定读取，Serializable 保障强一致性却伴随重试与长事务风险。选型应基于业务约束，而非盲目追求“最强”。
2026-10-27 11:20:14
345
原创 30 PostgreSQL ACID特性详解
本文深入解析 PostgreSQL 中 ACID 特性的实现机制，逐项剖析原子性（WAL 与 pg_xact）、一致性（约束与应用责任）、隔离性（MVCC 与隔离级别）和持久性（WAL 刷盘）的实现逻辑与代价。指出隔离性最难实现，因其需在正确性与并发性能间持续权衡；而 PG 通过默认选择“足够强”的保障，将更强或更快选项显式化，实现一致性与性能的灵活平衡。
2026-10-26 17:03:47
471
原创 29 PostgreSQL缓存管理与性能优化原理
PostgreSQL 缓存管理需理解“双层缓存”机制：shared_buffers 与操作系统 page cache 独立运作，过度增大前者会挤压后者，反而降低性能。25% 内存分配是合理起点，但非万能；命中率低于90%不必然需加内存，应优先优化查询、索引或处理表膨胀。关键指标如 buffers_backend 和可用内存需持续监控，最终以真实查询延迟验证调优效果。
2026-10-26 16:56:08
532
原创 AI时代首先数据库-PostgreSQL实战笔记 | 28 PostgreSQL MVCC机制介绍
本文深入解析 PostgreSQL 的 MVCC 机制，揭示其如何通过“保留旧版本、生成新版本”实现读写不阻塞。核心在于 xmin/xmax 标记行版本生命周期，结合事务快照进行可见性判断。虽提升并发性能，但带来表膨胀与事务 ID 回卷风险，依赖 VACUUM 清理死元组并冻结旧事务 ID。强调 autovacuum 重要性，提醒监控 datfrozenxid 与长事务管理。理解 MVCC 即掌握 PostgreSQL 并发设计的灵魂与运维关键。
2026-10-25 12:49:22
234
原创 AI时代首先数据库-PostgreSQL实战笔记 27 PostgreSQL数据写入与读取流程解析
一次 UPDATE 从执行到落盘，经历解析、分析、计划、执行、WAL记录、提交与脏页刷盘七个阶段，核心是“日志先行”：数据先在内存中更新，通过 WAL 保证持久性，实际落盘由 Checkpointer 异步完成。而 SELECT 则依赖缓存，若数据页已在 shared_buffers 或 OS page cache 中，可零磁盘读取，性能取决于缓存命中率。写入影响读取（如缓冲区竞争），读取也反哺写入（如减少全表扫描）。本质是：写靠 WAL 保安全，读靠缓存提速度。
2026-10-25 12:47:01
296
原创 AI时代首先数据库-PostgreSQL实战笔记 | 26 PostgreSQL background后台写进程
本文深入解析PostgreSQL后台进程的分工：background writer（维持空闲缓冲区）、checkpointer（建立恢复点）、walwriter（异步刷WAL）、autovacuum（清理死元组与防回卷）及统计收集器（可观测性数据源）。澄清常见误区，如bgwriter非“小号checkpointer”，强调其“供给”与checkpointer“一致点”的本质区别。结合参数调优实践，揭示各进程在数据写入生命周期中的协同机制，为高性能配置提供清晰指引。
2026-10-24 17:28:21
253
原创 AI时代首先数据库-PostgreSQL实战笔记 | 25 PostgreSQL checkpoint与脏页处理机制
Checkpoint 是 WAL 机制中确保崩溃恢复效率的关键环节，其核心作用是标记一个“数据已落盘”的安全点，从而缩短恢复时需重放的 WAL 范围。它由 checkpoint_timeout 与 max_wal_size 共同触发，通过 checkpoint_completion_target 实现平滑刷脏，避免 I/O 飙升。频繁 checkpoint 虽能提升恢复速度（RTO），却会因 full_page_writes 导致 WAL 量激增、日常写压力上升。调优本质是在恢复速度与运行稳定性间权衡：优先
2026-10-24 17:26:58
432
原创 AI时代首先数据库-PostgreSQL实战笔记 | 24 PostgreSQL WAL日志与崩溃恢复原理
PostgreSQL 通过 WAL（Write-Ahead Logging）实现数据持久性与崩溃一致性：先写日志再更新数据，利用顺序写提升性能，并以全页写防范部分写损坏。事务提交时等待 WAL 持久化，确保即使断电也能恢复。崩溃恢复从最近检查点开始，按 LSN 顺序重放 WAL，前滚所有变更。检查点频率影响恢复速度与 WAL 大小，段文件循环复用，归档需先完成。WAL 是一笔“用顺序写换随机写”的交易，保障数据安全与一致性。
2026-10-23 20:24:19
432
原创 AI时代首先数据库-PostgreSQL实战笔记 | 23 PostgreSQL数据库文件系统与数据页结构
PostgreSQL 以 8KB 页为磁盘 I/O 基本单位，页内通过行指针与空闲空间动态管理元组，支持 MVCC 与 VACUUM。当行数据超过页容量时，TOAST 机制自动压缩并行外存储大字段（如 text、jsonb），主表仅保留 18 字节指针。默认 EXTENDED 策略平衡空间与性能，EXTERNAL 可加速子串操作。虽提升缓存效率、减少主表负担，但读取完整大字段将引发额外 I/O 与 CPU 消耗，且 TOAST 表膨胀可能带来隐性风险。合理使用存储策略，避免 SELECT * 触发 de-T
2026-10-23 20:22:48
304
原创 基于springboot+vue+mysql「校园二手教材循环交易」小程序，三端全跑通
本文介绍了一个完整的校园二手教材循环交易平台「拾光流转」，基于SpringBoot3、Vue3与微信小程序实现三端全通。项目涵盖用户登录、商品发布、订单状态机、积分体系及管理后台数据看板，创新引入“漂流积分”机制促进闲置流转。针对答辩常见问题，重点解析了微信登录替代方案、订单状态机设计、本地ISBN书库的防腐架构，以及积分流水可追溯等核心设计决策，强调系统可运行性与工程化思维，具备高演示价值与答辩说服力。
2026-10-22 15:15:52
1378
原创 AI时代首先数据库-PostgreSQL实战笔记 | 22 PostgreSQL实例与集群
本文厘清 PostgreSQL 中实例、集群、数据库、模式与表空间的层级关系。实例为共享内存、WAL 和进程的物理单元；数据库提供逻辑隔离与权限控制，但不隔离资源；模式用于同一库内对象命名空间管理；表空间是唯一可控制数据物理位置的机制，支持跨库存储与冷热数据分离。多数据库间共享 WAL 与资源，备份恢复需全实例操作；表空间可通过设置 I/O 成本参数优化查询计划。核心结论：逻辑隔离 ≠ 资源隔离，表空间仅解决存储层调优，无法突破实例级共享瓶颈。
2026-10-22 14:54:26
210
原创 AI时代首先数据库-PostgreSQL实战笔记 | 21 PostgreSQL进程与内存架构介绍
本文深入解析 PostgreSQL 的运行架构，揭示其多进程模型下各组件的职责与协作机制。Postmaster 作为父进程负责初始化共享内存、管理 backend 及辅助进程；每个客户端连接对应独立 backend 进程，实现故障隔离与稳定性保障。核心辅助进程如 Checkpointer、Background Writer、WAL Writer 分工明确，协同保障数据一致与性能。内存方面，共享内存（shared_buffers）与私有内存（work_mem）分工清晰，且存在“双缓冲”现象——shared_b
2026-10-22 14:52:06
140
原创 AI时代首先数据库-PostgreSQL实战笔记 | 20 PostgreSQL物理备份：pg_basebackup与PITR
物理备份通过 pg_basebackup 与 WAL 归档结合，实现大库快速恢复与精确 PITR。其核心优势在于恢复时仅需文件复制与 WAL 回放，避免逻辑备份的索引重建开销，显著提升 RTO。但代价是无法选择性恢复，且版本必须一致。生产中常以基线备份+持续归档构建完整灾备体系，配合 recovery.signal 和 recovery_target_* 参数实现时间点恢复，每次恢复生成新时间线，确保数据一致性。
2026-10-21 17:49:47
365
原创 AI时代首先数据库-PostgreSQL实战笔记 | 19 PostgreSQL逻辑备份：pg_dump与pg_dumpall
本文深入解析PostgreSQL逻辑备份的核心机制与实操要点，厘清pg_dump、pg_dumpall、pg_restore的分工边界，详解四种备份格式（plain/custom/directory/tar）的适用场景，强调并行备份仅支持directory格式，而并行恢复可覆盖custom与directory。重点揭示“备份可恢复性验证”的三层实践：文件可读性检查、测试库冒烟恢复、自动化恢复演练，并指出物化视图需手动刷新。最后对比逻辑与物理备份的优劣，明确二者互补关系——逻辑备份适配迁移、选择性恢复，物理备
2026-10-21 17:41:44
371
原创 AI时代首先数据库-PostgreSQL实战笔记 | 18 PostgreSQL基本索引原理与创建
主题关键点B-tree 结构平衡树，分裂向上传播，根分裂才长高fillfactor默认 90，随机写入可降低以减少分裂；只作用于叶子页复合索引最左前缀；等值列在前，范围列在后部分索引只索引稳定过滤条件下的子集，体积小、维护低表达式索引查询中的表达式必须与索引定义完全匹配覆盖索引INCLUDE载荷列，实现 Index Only Scan失效场景隐式转换、函数包裹、前导通配符、最左断裂、选择率过高维护膨胀 >30% 考虑 REINDEX；删除未使用索引。
2026-10-20 15:24:39
475
HeidiSQL-12.21-64-Portable
2026-09-17
OpenJDK17.0.13-win-x64.zip免安装解压版-解压配置 JAVA-HOME 直接使用
2026-09-04
考研加油上岸祝福软件弹窗程序
2026-02-23
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人