上周团队开会，新来的架构师小伙儿在白板上画满了各种数据库的对比矩阵，一本正经地分析着QPS、TPS、CAP理论。看着他认真的样子，我突然想起二十年前，自己第一次坐在Oracle OCP培训课堂里的情景。那时候的老师拍着胸脯说：”学会了Oracle，这辈子不愁饭吃。”二十年过去了，Oracle我还在用，但数据库的世界已经天翻地覆。

这些年，我亲手埋过的”数据库选型坑”足够写一本错题集。今天不聊高深理论，就聊聊那些让我半夜被电话叫醒的真实故事，以及血泪中总结出的决策框架。

一、Oracle时代：我们曾是”存储过程”的信徒

2004年，我第一个正式项目是给某银行做核心交易系统。甲方爸爸一句话：”必须用Oracle，预算不是问题。”那时候的我，看着OEM管理界面里花花绿绿的性能图表，真心觉得这就是技术的巅峰。

我们团队当时信奉”让数据库做它该做的事”，业务逻辑几乎全写在存储过程里。一个PROCEDURE_CALCULATE_INTEREST函数能写两千多行，嵌套了七八层游标。性能确实快，但噩梦也随之而来。

踩坑现场：某天业务要调整计息规则，产品经理拿着需求文档找我。我打开那个两千行的存储过程，花了整整一天才理清逻辑。更崩溃的是，测试环境根本没有足够的数据量来验证修改是否正确。最后只能半夜上线，我守在电脑前，手心全是汗。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- 当年引以为豪，现在不忍直视的代码
CREATE OR REPLACE PROCEDURE process_transaction(
    p_account_id IN NUMBER,
    p_amount IN NUMBER
) IS
    v_balance NUMBER;
    v_status VARCHAR2(20);
    CURSOR c_history IS SELECT * FROM trans_log WHERE account_id = p_account_id;
BEGIN
    -- 这里省略了2000行业务逻辑
    FOR rec IN c_history LOOP
        -- 层层嵌套的业务判断
        IF rec.trans_type = 'DEBIT' THEN
            -- 更多逻辑...
        END IF;
    END LOOP;
EXCEPTION
    WHEN OTHERS THEN
        -- 最坑的是这里，异常处理几乎没做
        NULL;
END;

心得：Oracle是好，但把它当应用服务器用，就是灾难的开始。存储过程适合处理纯数据逻辑，但业务规则频繁变化的场景，一定要往上层迁。这个教训让我在后来的十年里，始终坚持”数据库只存数据，业务逻辑放在应用层”。

二、MySQL分库分表：当”Sharding”成为噩梦代名词

2010年，互联网浪潮来了。我跳到了一家电商公司，Oracle的授权费用让老板脸都绿了。”全切MySQL，立刻，马上！”这是CTO的原话。

起初很美好，MySQL 5.1跑单表千万级数据毫无压力。但半年后，订单表突破一亿行，查询慢得令人发指。于是我们走上了分库分表的不归路。选了当时最火的分片中间件，信心满满地设计了16个库，每个库64张表。

踩坑现场：第一次做跨库查询时，我傻眼了。要统计某个用户的全平台消费总额，需要聚合16个库的查询结果。更惨的是分页，limit 10, 10这种简单操作，变成了分布式系统的经典难题。最崩溃的是有一次，某个分片的数据库服务器磁盘满了，导致部分用户订单列表显示不全，我们花了6个小时才定位到问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 当年为了处理分库分表写的"丑陋"代码
public List<Order> getUserOrders(Long userId, int page, int size) {
    // 先算用户在哪个库
    int dbIndex = (int)(userId % 16);
    // 再算在哪个表
    int tableIndex = (int)(userId % 64);
    
    // 拼接表名
    String tableName = "order_" + tableIndex;
    
    // 每个分片都要查，最后归并排序
    List<Order> allOrders = new ArrayList<>();
    for(int i = 0; i < 16; i++) {
        DataSource ds = shardingDataSources.get(i);
        // 查询逻辑...
        // 内存中手动排序分页，JVM频繁OOM
    }
    return allOrders.stream()
        .sorted(Comparator.comparing(Order::getCreateTime).reversed())
        .skip(page * size)
        .limit(size)
        .collect(Collectors.toList());
}

文章插图

心得：分库分表不是银弹，它把数据库的复杂性转移到了应用层。如果团队没有中间件开发能力，慎选！后来我们迁移到TiDB时，第一件事就是把这层”sharding逻辑”全删掉，那种解脱感，比还清房贷还爽。

三、NoSQL狂欢：MongoDB让我学会”场景适配”

2014年，NoSQL风头正劲。我负责的一个社交项目，用户动态数据结构多变，字段今天加明天减。MySQL的ALTER TABLE让我们痛苦不堪。”上MongoDB，schemaless，完美适配！”技术会议上，我拍着桌子说。

确实，前三个月开发效率飞起。嵌套文档、数组字段、动态查询，MongoDB的灵活性让我们如鱼得水。直到某天，运营要统计用户的点赞行为，我们才发现——MongoDB的聚合框架在大数据量下慢如蜗牛。

踩坑现场：一个看似简单的统计需求：db.user_feed.aggregate([{$unwind: "$likes"}, {$group: {_id: "$likes.userId", count: {$sum: 1}}}])，在千万级文档下跑了整整20分钟。更糟的是，我们发现90%的查询其实都需要按固定字段查询，所谓的”schemaless”优势根本没用到，反而因为缺乏schema约束，数据质量一塌糊涂。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 理想很丰满的文档设计
{
  userId: 12345,
  feedContent: "今天天气真好",
  likes: [
    {userId: 111, timestamp: ISODate("2024-01-01")},
    {userId: 222, timestamp: ISODate("2024-01-02")}
  ],
  comments: [
    {userId: 333, content: "确实不错", replies: [...]}
  ]
}

// 现实很骨感：查询某个用户点赞过的所有动态，性能灾难
db.user_feed.find({"likes.userId": 111}) // 全表扫描！

心得：NoSQL不是MySQL的替代品，它是补充。我现在做选型，第一件事就是画查询场景矩阵：如果70%以上的查询是结构化查询，需要事务支持，那就乖乖用关系型数据库。只有明确需要灵活数据结构、高并发写入、弱一致性场景，才考虑MongoDB或Redis。千万别为了”时髦”而选型。

四、NewSQL曙光：TiDB让我重新相信分布式

2018年，公司B轮融资到位，业务要冲百亿GMV。数据库再次成为瓶颈，这次我死活不愿再走分库分表的老路。调研了一圈，选定了TiDB——号称兼容MySQL协议、弹性扩展的NewSQL。

部署测试集群，把MySQL数据同步过去，运行压测。当TPC-C数据跑出来时，我激动得差点哭出来。线性扩展真的存在！更惊喜的是，TiDB的HTAP能力让实时报表查询不再需要同步到专门的分析库。

踩坑现场：上线初期，我们遇到了一个诡异的问题：某条SQL在MySQL里秒出结果，在TiDB里却超时。排查发现，TiDB的优化器对索引的选择策略不同，导致执行计划偏差。通过EXPLAIN ANALYZE发现，它错误地选择了全表扫描。最后通过手动指定索引hint解决，但这个过程让我意识到：兼容不等于完全一致。

1
2
3
4
5
6
7
8
9
10
11
-- MySQL中表现良好的查询
SELECT * FROM orders WHERE user_id = 123 AND status = 'PAID';

-- TiDB中需要优化的版本
SELECT /*+ USE_INDEX(orders, idx_user_status) */ * 
FROM orders 
WHERE user_id = 123 AND status = 'PAID';

-- 监控TiDB集群的命令成了日常习惯
SHOW PROCESSLIST;  -- 看慢查询
SELECT * FROM information_schema.TIDB_HOT_REGIONS; -- 热点region排查

文章插图

心得：NewSQL是分布式数据库的正确方向，但迁移不是零成本。团队需要学习新的排查工具、理解分布式事务的延迟特性、接受最终一致性的某些场景。建议先在小业务线试点，培养1-2个”救火队员”，再全面推广。

五、云原生时代：从”选数据库”到”选服务”

2021年，我加入现在的公司，一家云原生SaaS企业。数据库选型问题变成了：用AWS RDS还是Aurora？要不要试试Serverless？自建Kubernetes部署Operator？

老板给了我一个原则：”别碰硬件，别养DBA团队。”于是我们全线拥抱云托管数据库。Aurora的存储计算分离确实很香，自动扩缩容让我们撑过了几次秒杀活动。但账单出来的时候，财务总监的脸色比当年Oracle的报价单还难看。

踩坑现场：开发环境的数据库实例忘了关，一个月烧了3万美金。生产环境的Aurora因为配置了跨Region只读副本，网络流量费用比实例费还贵。更隐蔽的是，Serverless数据库的”冷启动”延迟，导致我们一个核心接口的P99延迟突然飙到2秒，用户投诉如潮。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 我们现在的IaC配置，成本优化是首要任务
# Terraform配置片段
resource "aws_rds_cluster" "prod" {
  engine                 = "aurora-mysql"
  engine_version         = "8.0.mysql_aurora.3.02.0"
  # 关键：根据业务波峰波谷设置容量
  serverlessv2_scaling_configuration {
    min_capacity = 4   # 低谷时降低成本
    max_capacity = 128 # 高峰时保证性能
  }
  
  # 血泪教训：必须设置自动暂停
  # 但核心库千万别开，否则用户体验崩了
  enable_http_endpoint = false
}

心得：云数据库把运维复杂度变成了成本管理复杂度。我现在做选型，会先做一张TCO（总拥有成本）模型表：不仅算实例费，还要算网络、存储、备份、跨区流量、API调用费。更重要的是，理解云服务的”隐性约束”——比如Aurora有6TB单表限制，Serverless有连接池冷启动问题。没有完美的云服务，只有适合业务模式的成本结构。

六、我的决策框架：四象限+三原则

二十年踩坑无数，我总结出一个实用的选型框架。每次有新项目，我会先画两个四象限：

第一个四象限：业务场景维度

  • X轴：数据一致性要求（强一致 → 最终一致）
  • Y轴：查询复杂度（简单KV → 复杂多维分析）

第二个四象限：团队能力维度

  • X轴：运维能力（强 → 弱）
  • Y轴：开发熟悉度（熟悉SQL → 熟悉NoSQL）

然后把候选数据库放进去，交集区域就是”安全选择”。

但更重要的是我坚守的三个原则：

原则一：能不用分布式就别用
除非单机MySQL/PostgreSQL真的撑不住，否则别为了”前瞻性”上分布式。单机数据库的debug能力、工具生态、人才储备，是分布式永远比不了的。我们有个中台系统，数据量才500万，前任架构师上了TiDB，结果一个简单的JOIN问题，团队搞了三天才定位到是Region调度导致的。

原则二：优先选择团队会用的
再牛逼的数据库，团队不会用就是灾难。2022年我们考虑过CockroachDB，地理分区功能很诱人。但团队里没人懂Go语言，无法深入排查问题。最后选了PostgreSQL+分区表，虽然方案”土”了点，但稳定运行至今。技术选型不是选美，是选”能睡安稳觉”的方案。

原则三：预留逃生通道
无论选什么数据库，必须设计”逃生方案”。我们用MongoDB时，同时搭建了Change Streams同步到Kafka，万一MongoDB扛不住，可以迅速切换到备用方案。云数据库更要定期做”厂商锁定”评估，每季度导一次全量数据到S3，确保被云厂商绑架时有谈判筹码。

写在最后

上周，那个在白板上画矩阵的架构师小伙儿又找我，说他决定用某国产分布式数据库。我问他：”你们团队有人会修WAL日志吗？如果不会，先别急。”他愣住了。

数据库选型没有标准答案，只有阶段性最优解。Oracle教会我尊重数据一致性，MySQL让我理解简单的美，NoSQL让我警惕过度设计，NewSQL让我相信技术演进，云原生让我学会成本权衡。

现在的我，面对数据库选型，会先泡杯茶，静静地问三个问题：团队能驾驭吗？业务真需要吗？半夜挂了能修好吗？如果答案都是肯定的，那就干。否则，宁可保守一点，也别让未来的自己在凌晨三点骂娘。

毕竟，数据库这东西，不出问题的时候你觉得它很酷，出问题的时候你只希望自己还在睡觉。