一、为什么数据库选型决定性能天花板？
很多团队在业务初期只关注功能实现，却忽略了数据层选型对后期扩展的影响。错误的选型会让性能优化事倍功半，而正确的选型则能把优化成本降到最低。
（图片来源网络，侵删）
自问自答：
- Q：MySQL 扛不住高并发写入怎么办？
- A：先确认瓶颈是磁盘 I/O 还是行锁冲突，再考虑分片或迁移到 LSM-Tree 结构的存储引擎。
二、关系型还是 NoSQL？先厘清四大维度
1. 数据结构复杂度
强事务、多表 JOIN 场景优先选 PostgreSQL / MySQL InnoDB；嵌套文档、灵活 schema 则考虑 MongoDB、Couchbase。
2. 读写比例与一致性要求
- 读多写少：Redis + MySQL 读写分离
- 写多读少：Cassandra、ScyllaDB 的追加写模型
- 强一致性：仍回到传统 RDBMS，配合悲观锁或 MVCC
3. 扩展方式
垂直扩展总有上限，水平分片才是长期方案。MySQL 分片需要中间件（ShardingSphere、Vitess），而原生分布式数据库如 TiDB、CockroachDB 省去这一层。
4. 运维成本
自建集群需要 DBA、监控、备份、容灾；云托管（Aurora、AlloyDB）把 70% 的运维工作交给厂商，但需评估锁仓风险。
三、性能优化三板斧：索引、缓存、分片
索引：90% 慢查询的元凶
常见误区：
（图片来源网络，侵删）
- 给所有 WHERE 字段建单列索引 → 复合索引顺序更重要
- 忽略覆盖索引 → 回表一次就多一次随机 I/O
- 不更新统计信息 → 优化器选错执行计划
最佳实践：
- 使用
EXPLAIN ANALYZE观察实际行数与预估行数差异 - 把选择性高的列放在复合索引左侧
- 长文本用前缀索引，避免 767 字节限制
缓存：别让数据库做重复劳动
多级缓存架构：
- L1：应用内存（Guava Cache、Caffeine）
- L2：分布式缓存（Redis/Memcached）
- L3：CDN 边缘节点
自问自答：
- Q：缓存击穿怎么防？
- A：热点 key 加互斥锁 + 逻辑过期时间，或使用布隆过滤器拦截空值。
分片：水平拆分还是垂直拆分？
| 维度 | 水平拆分 | 垂直拆分 |
|---|---|---|
| 数据量 | 单表过大 | 单库过大 |
| 访问模式 | 按用户 ID 哈希 | 把冷热字段拆到不同表 |
| 事务 | 需要分布式事务 | 本地事务即可 |
注意：分片键一旦确定几乎不可变更，务必预留 2-3 年业务增长空间。
四、云原生时代的性能新变量
Serverless 数据库的冷启动问题
Aurora Serverless v2 宣称秒级弹性，但第一次连接仍可能耗时 500ms+。对延迟敏感的场景需保持最小预置容量。
存算分离架构的利弊
- 利：存储层独立扩缩容，计算节点无状态易迁移
- 弊：网络带宽成为新瓶颈，需开启 RDMA 或压缩算法
自动调优工具靠谱吗？
AWS Performance Insights、阿里云 DAS 能给出索引建议，但不会理解业务语义。例如推荐给订单表加索引，却忽略了月底批量结算会锁全表。
五、实战：从 1 万 QPS 到 10 万 QPS 的演进路径
阶段一：单机优化
业务上线 3 个月，QPS 1 万，CPU 70%，磁盘 util 90%。
- 把
sync_binlog=1改成 1000，刷盘频率降低 - 关闭
query_cache，命中率不足 5% 反而拖慢写入 - SSD 替换 SATA，随机写 IOPS 提升 6 倍
阶段二：读写分离
QPS 3 万，主库 CPU 90%，从库 20%。
- 业务代码识别读写操作，写走主库，读走从库
- 引入 ProxySQL 做连接池和故障转移
- 监控主从延迟，超过 1 秒触发报警
阶段三：分库分表
QPS 8 万，单表 2 亿行，索引深度 4 层。
- 按用户 ID 取模 64 分片，单表降至 300 万行
- 使用 ShardingSphere-JDBC，业务零改动
- 分布式主键用雪花算法，避免自增 ID 热点
阶段四：缓存+队列削峰
大促峰值 10 万 QPS，其中 40% 是重复查询。
- Redis 缓存命中率提升到 85%，数据库 QPS 降至 6 万
- 库存扣减改为异步消息队列，避免行锁竞争
- 最终一致性通过定时对账补偿
六、未来趋势：HTAP 与 AI 调优
TiDB、SingleStore 等 HTAP 数据库试图打破 OLTP 与 OLAP 的边界，一份数据同时服务交易和分析，减少 ETL 链路。但混合负载下的资源隔离仍是挑战。
AI 调优方向：
- 基于强化学习的索引推荐（如 Oracle Autonomous Database）
- 异常检测：用机器学习识别慢查询模式，提前扩容
- 自动参数调优：根据历史负载预测最佳
innodb_buffer_pool_size
自问自答：
- Q：小公司需要追 HTAP 吗？
- A：先把单机优化做到极致，业务体量到 TB 级再考虑，否则只是增加复杂度。
评论列表