MySQL 开始分库分表时,别急着换国产数据库:先问完这五句
一个 MySQL 集群开始不好伺候,团队通常会经历同一串动作:加只读副本、拆热点表、按用户 ID 分库、路由写进中间件、跨库查询单独做服务。
最开始都觉得还能扛。
直到某次需求只是“查一下用户在所有店铺的订单”,代码评审里先出现的不是 …
一个 MySQL 集群开始不好伺候,团队通常会经历同一串动作:加只读副本、拆热点表、按用户 ID 分库、路由写进中间件、跨库查询单独做服务。
最开始都觉得还能扛。
直到某次需求只是“查一下用户在所有店铺的订单”,代码评审里先出现的不是 …
你做了一个日志系统。
数据量每天 500GB,全是 APP 行为埋点。你选了 MySQL InnoDB,因为团队最熟。跑了一个月,写入越来越慢,到了夜里还要锁表清理。DBA 说:要不试试换 RocksDB?
你换了一版。写入快了很多,但查询 …
PG 大版本升级,过去一直有两件烦心事:
一是升完了统计信息丢光,优化器两眼一抹黑,ANALYZE 跑完之前查询崩好几天。二是折腾半天,性能提升不明显,不值得冒这个险。
PG 18 把这两件事都动了。
而且这次不是小步迭代——几个改动直接改 …
很多后端团队有一个很顽固的默认值:能上 Postgres,就上 Postgres。
配置表放 Postgres,后台任务状态放 Postgres,内部仪表盘也查 Postgres。哪怕那张表一天写不了几次,哪怕服务只是读几个本地状态,大家还 …
线上报 connection pool exhausted,我见过不少人的第一反应是把 max_open 调大。
从 20 调到 100,报警没了,接口也稳了。看起来问题解决了。
直到另一个服务把它调到 200,还是超时;DBA 又在群里说 …
上一篇《MySQL 千疮百孔,为什么没人能替代它》发出去之后,收到的留言比我预想的多。大部分不是技术讨论,是一种很微妙的共鸣:我知道它有问题,但我确实不知道该不该换。
这其实才是真正的困惑。
你看完 MySQL 那堆坑——ENUM 排序按定 …

技术评审会上,最尴尬的不是没人知道 MySQL 有坑。
最尴尬的是,所有人都知道它有坑,最后还是选它。
有人说 PostgreSQL 更严谨,有人说 MySQL 的外键、触发器、枚举、事务边界都要小心,有人甚至能现场背出几个历史遗留问题。 …
你只是改了一下订单状态,结果买家表被锁住了。
订单状态在订单表里。买家信息在买家表里。按正常直觉,这两个动作不该互相打扰。外键要保护的是买家 ID 这种关联字段,不是订单状态这种业务字段。
但 MySQL 里事情偏偏就这么发生了:因为订单状 …
现代软件工程已经基本变成了"订阅管理模拟器"。
我们被云厂商洗脑了,以为即使构建一个基础应用,也需要拼凑一个脆弱的分布式网络:
很多开发者天天在用 PostgreSQL,但只要你追问三个问题,场面就会立刻安静下来:它为什么并发强?为什么崩了还能恢复?为什么 JSONB、大文本这些大字段没把系统拖死?
如果这些问题你平时很少认真想过,那你多半还停留在“会用 …
这是世界上最先进的开源关系型数据库。
PostgreSQL 的能力早已超越了传统关系型数据库的范围。现代开发中,为了解决各种问题,各类花哨的工具层出不穷——缓存用 Redis、全文检索用 Elasticsearch、文档存储用 …
1974 年,IBM 捣鼓出了世界上第一个关系数据库。
50 年过去了,Oracle、MySQL、PostgreSQL 这些 RDB 依然霸榜。年轻程序员嘴上喊着 “SQL 太土”,项目里该用还是用。
有意思的是,每 …
用了 MySQL 好几年,最近深入研究 PostgreSQL,才发现自己一直在将就。
不是 MySQL 不好,而是 PostgreSQL 在太多地方更胜一筹。这篇文章从四个维度把它说清楚:索引、数据一致性、性能、扩展性。