压测时 Agent 读到了三小时前的数据 7 月 18 日我们对知识问答 Agent 做季度压测。压到 1,200 QPS 的时候，测试同学反馈一个问题：刚在后台改的商品价格，问 Agent 还是旧值。 一开始我以为是缓存。查了一圈发现不是——向量库里的切片更新时间是三小时前，而业务库的变更早就提交
同事在群里甩了一张截图 上周三下午，运营在群里 @ 我，配了张图：用户问"退款多久到账"，机器人答"7 个工作日内"。而政策文档在 6 月 2 日就改成了"3 个工作日"。 后台里那份 PDF 更新时间是 6 月 2 日 15:47，状态"已解析、已入库"。文档是新的，索引里的内容是旧的。 这篇记录
向量检索选型：我们算了一笔账，最后没上专业向量库 十月份做知识库检索重构，团队里争论要不要上 Milvus 或者 Qdrant。我们已经在用 PostgreSQL（存业务数据 + 元数据），pgvector 扩展是顺手的选择，但大家都担心性能不行。 最后我们做了完整的压测和成本核算，结论是继续用 p
知识库从 5 万文档涨到 320 万，第一版设计撑不住了 我们公司的知识库最早是给客服用的，5 万篇 FAQ，存储设计得很随意：一张 kb_doc 表，切片直接以 JSON 数组的形式塞在 chunks 字段里，向量存在 Milvus 里，两边用 doc_id 关联。 这个设计在 5 万篇的时候完全
CR 时跟同事吵了一架 上周做订单模块的代码评审，同事设计的新表里有个 ext_data 字段，类型 json，里面塞了发票信息、优惠券信息、配送偏好、渠道来源，一共十几个子字段。他的理由是"这些字段每个订单不一定都有，建十几个列太浪费"。 我在评论里提了反对意见，他回了一句"MySQL 8 原生支
周五下午 16:42，37 万行订单没了 11 月 15 号周五，下午四点四十二，我正准备收拾东西下班，监控群里炸了。 [16:42:07] 告警：order_center 慢查询数 5 分钟内 0 → 143 [16:42:31] 告警：order_center QPS 从 3800 跌到 41
文档下线三天了，客服机器人还在引用它 9 月中旬出了个不大不小的故障。运营下架了一份过期的《海外退换货政策 V1》，三天后还有用户在客服机器人里问到"海外订单 30 天可退"，而新政策是 15 天。用户截图投诉到了客服主管那里。 我查了一圈，问题出在存储架构上。我们当时的 RAG 是这样的： MyS
背景：我们一套跑了五年的订单分析系统，主库是 MySQL 8.0，平时扛交易，月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%，复制延迟一度飙到 47 秒，运营看板直接瘫痪。那一刻我意识到，把 OLTP 和重分析塞在同一套实例里，迟早出事。 为什么盯上 TiDB 当时评估了三个
背景：4.x 到 5.x 的跨代升级 八月底我们把分库分表中间件从 ShardingSphere 4.1 升到 5.3。4.x 用的还是旧的 sharding-jdbc 单库形态，配置散在 Spring 的 xxx.yaml 里；5.x 统一成了 shardingsphere-jdbc，配置模型完全
告警：一条 JOIN 把从库 CPU 拉满 七月五号，DBA 在群里 @我：「你那条报表 SQL 把从库 CPU 干到 100%，跑了 40 秒还没出」。这是一条订单表（8000 万行）和用户表（2000 万行）的关联查询，原本是凌晨跑的批，被临时拉到白天查。我拿 EXPLAIN 一看，问题很清楚。
