So You Want to Migrate to Postgres
TL;DR A data-technology migration is five migrations stacked on top of each other: the query surface, the coupling around it, the data itself, the operational model, and the long tail. Teams that esti...
评论
点赞
收藏The 2025 DORA Report Is Quietly About Your Database
TL;DR The 2025 DORA report found AI raises delivery throughput and hurts delivery stability at the same time, and its AI Capabilities Model names seven things that decide which way that goes for a tea...
排序规则漂移：无声的索引杀手
MySQL 从 5.7 升级到 8.0 后，混用 utf8mb4_general_ci 和 utf8mb4_0900_ai_ci 排序规则会导致 JOIN 失败或索引失效。文章通过真实案例展示了隐式字符集转换如何使索引失效，并指出统一排序规则的修复方案可能因相等性定义改变而引发主键冲突。
跨数据库连接：直到拆分时才看得见的耦合
同一MySQL实例上跨Schema的JOIN看似免费，实则是系统拆分的硬耦合。当业务需要水平拆分以扩展规模时，这些隐式关联会成为巨大的迁移障碍，且原有的引用完整性约束在拆分后失效。
通过健康检查和监听脚本实现数据库自愈
利用Consul等服务的健康检查和Watch机制，实现数据库的窄范围自愈。提供了具体的工程思路，将基础设施监控能力转化为数据库运维方案，具有明确的实操价值和架构讨论空间。
在坏数据写入之前：应对静默数据损坏的新思路
传统备份和复制机制旨在应对故障，但数据静默损坏会迅速被复制并保留在备份中，往往在数周后才被发现，此时已超出保留窗口。 文章提出解决数据损坏的核心在于建立数据溯源（provenance），通过追踪写入来源来识别并回滚错误的修改，而非仅仅依赖副本恢复。
设计无需人工维护的数据库分区方案
文章指出按时间分区会导致主键变更和查询泄漏，建议改用主键ID分区并由后台服务自动管理边界。 这种方案让查询无需修改即可享受分区裁剪，同时通过服务动态对齐时间边界以支持数据保留策略。
扩展模式而非实例：从根源解决系统性故障
文章指出大多数生产环境的修复只是针对眼前问题的临时补丁，虽然解决了当下问题，但导致同类故障反复发生。真正的解决方案需要在更高层面进行干预，通过改变模式来覆盖所有未来可能出现的实例。 这种思维方式要求工程师区分“偶发事件”与“系统性问题”，在实施修复前判断故障是孤例还是类问题，从而制定能根治而非仅缓解症状的策略。
千刀万剐：那些绕过所有防护的 AI 数据库故障
文章指出，AI 生成的数据库代码往往在审查时看似正确，但随着数据积累导致性能崩溃或逻辑错误。这类“静默且不可恢复”的错误比明显的破坏性错误更难发现。 作者通过爬虫表膨胀和软删除漏计两个案例，说明现有审核流程无法拦截此类问题。建议通过业务级对账和限制 AI 访问敏感写入路径来缓解风险。
窄工具与窄智能体：Agent 可靠性究竟从何而来
幻觉最少的 AI 智能体使用的是狭窄、专有的工具，并被赋予最小的任务范围。返回布尔值和延迟数的诊断端点优于通用的 SQL 查询接口。 拥有三个工具的受限智能体比拥有广泛工具的智能体更可靠，这揭示了 Agent 可靠性的真正来源。
总是查询的问题（第五部分）：磁盘有两个警报，而非一个
文章指出磁盘问题通常有两个警报：容量不足和性能下降。容量问题应通过分区归档解决，而非删除数据；性能问题则需优化覆盖索引以匹配访问模式。 云环境的自动扩展往往掩盖了底层的查询效率问题，导致资源浪费。作者强调从查询层面和Schema层面寻找长期有效的解决方案，而非依赖临时扩容。
总是查询的锅：第四篇——当排序发生溢出时
数据库内存告警通常不是因为整体内存不足，而是排序或哈希操作产生的瞬时、并发内存分配导致的。 文章解释了为什么实例级内存监控往往无法捕捉到这些危险的局部峰值，以及它们如何导致性能问题。
总是查询的锅（三）：当 CPU 满载时
关系型数据库 CPU 占满通常不是因为单个昂贵查询，而是廉价查询执行次数过多。慢查询日志和平均耗时排序往往忽略这一点，只有总执行时间视图能发现它。 作者通过客户端门户下拉菜单案例，展示了如何通过分析总执行时间来定位这种高频低耗的性能瓶颈。
几乎总是查询的问题（二）：故障排查步骤
本文介绍了一套可重复的数据库故障排查流程：先观察当前状态，再分类等待类型，接着缩小具体原因，最后采取行动。 作者强调这套逻辑顺序比使用的工具更重要，旨在帮助不常处理此类问题的工程师掌握排查技能。
几乎总是查询的问题（一）：为什么增加硬件配置帮不上忙
基础设施警报几乎总是源于查询和模式选择，而非容量问题。扩容只是租用bug。 作者指出复制延迟、CPU满载等问题的根源通常在SQL层面。
向 Agent 暴露数据：MCP 协议与专用 API 的抉择
文章对比了将数据暴露给 AI Agent 的两种方案：直接连接数据库或使用专用 API。作者认为在非生产环境中直接连接数据库便于探索，但在生产环境中应使用带有权限控制和行限制的保护层 API。 这反映了当前大模型应用开发中的实际工程权衡。
10 倍效率提升是真实的：仅限那些你原本不会发布的内部工具
AI 编程代理在从零开发内部工具时确实能实现 10 倍效率提升，因为代理可以生成代码并遵循自身约定的规范。但在维护现有服务、跨团队协作或受监管的代码路径中，效率增益压缩至 10-30%，甚至可能因成熟代码库的复杂性而变成负面效果。
为何要用 AI Agent 辅助季度绩效评估
作者建议利用 AI Agent 自动化处理季度绩效评估中从 Jira、GitHub 等多源收集证据的机械性工作，从而节省时间。 管理者应将节省下来的精力集中在评级、晋升或淘汰等需要判断力的核心决策上，并确保所有结论均有据可查。
AI 部署中被忽视的数据库成本：存储、CPU、内存与缓存
在现有 Postgres 中添加 RAG 会导致受影响表的存储增加 5 倍，HNSW 索引内存消耗剧增且无法优雅降级，并严重污染缓冲缓存，导致无关 OLTP 查询的 p95 延迟恶化。 文章建议采用 halfvec、带重排的二进制量化以及分离的重新索引策略来缓解这些问题。
你的告警分类不需要自主智能体
作者认为在告警分类场景中，构建复杂的自主智能体是过度设计。 推荐采用脚本化查询结合单次LLM调用的方案，既节省时间又保留原始数据供人工复核。
If Your Guardrail Is a Prompt, You Don't Have a Guardrail
TL;DR A prompt instruction biases the next-token distribution. It cannot bound it. Real guardrails for agents holding production credentials sit below the prompt, in layers the model cannot read or ov...