在软件开发的生命周期里，你总会遇到一个时刻——
“数据库是不是该优化一下了？”

我在电商行业干了 15 年，大促、活动、跨国业务扩张、读写分离延迟……
经历了一轮又一轮性能瓶颈。
这一篇文章，就是把我踩过的坑、做过的优化，按最朴素的方式讲清楚。

其实数据库优化没有你想得那么玄乎，都是一个个很小的步骤，但整个优化过程就是围绕这些点来展开。

为什么要优化？先想清楚原因

你可能遇到：

主库压力过大？
QPS 快顶不住？
活动大促要来了？
要扩展到新业务 / 新国家？
主从同步有延迟？

不同系统可能有不同触发点，但优化方向基本都离不开下面这几个。

数据库优化 10 大核心步骤

1. 数据库拆分（DB Segregation）

先弄清楚你主库里都放了什么表：

静态表（变化不频繁，如商品基础信息）
动态表（写入频繁，如库存、价格、订单）

电商里常见场景：
供应商会不断更新“价格”和“库存”，这些表会被不断写入。

如果所有表混在一个库里，那么：

动态表的写入压力
可能会拖慢静态表的查询

因此，你应该考虑：

✔ 把静态和动态的表拆成不同库
✔ 把分析类 SQL（报表、BI）放到单独的库或专用从库

这样不会互相影响。

2. 数据归档（DB Size Reduction）

我们很多系统喜欢把历史数据全堆在主库里，想着“以防万一”。
但这会带来：

数据越多
→ 行越多
→ 查询越慢
→ 索引越大
→ CPU / IO 压力更高

解决方式：

✔ 把历史数据定期归档
✔ 主库只保留业务需要的“在线数据”
✔ 历史数据按需访问（如独立归档库）

这样主库会“轻松很多”。

3. SQL 查询优化（DB Query Optimization）

SQL 优化永远是第一生产力。

优化可以在：

应用层（ORM、SQL 写法）
数据库层（索引、执行计划）

这些技巧网上一大堆，我就不重复，但一定要记住：

✔ 坏 SQL 是性能杀手
✔ 线上慢查询一定要持续监控
✔ 索引不是越多越好，要“用得上”才加

MySQL 官方文档都有详细教程。

4. 找出主从延迟（DB Lag）

大部分系统都是：

主库写
从库读

但主从同步有可能出现延迟（master → slave 复制慢）。

常见原因：

慢 SQL 堵住 binlog
高并发写入
slave IO / CPU 不够
大事务

你可以：

✔ 打开慢查询日志，找出“罪魁祸首”
✔ 使用 GTID 同步模式（更稳定、更自动化）

GTID 会自动标记每个事务，能减少很多从库重启、重新同步的麻烦。

5. 数据库参数调优（DB Tuning）

很多人上线数据库后就从不调参数。
但 MySQL 默认配置不一定适合线上业务。

你需要关注：

① Query Cache（MySQL 8 已废弃，多了解即可）

看看缓存是否合适，命中率怎样。

② Buffer Pool Size

InnoDB 的核心参数。内存够大就调大，让更多数据能放进内存。

③ Page Size

越大越适合大表，但不建议轻易改，更多是理解概念。

简单讲：

✔ 足够的内存
✔ 合理的 buffer pool
✔ 避免不必要的 query cache

性能会明显提升。

举个例子：

mysql> SHOW STATUS LIKE “qcache%”;
+ — — — — — — — — — — — — -+ — — — — -+
| Variable_name | Value |
+ — — — — — — — — — — — — -+ — — — — -+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 1031320 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 1 |
| Qcache_queries_in_cache | 0 |
| Qcache_total_blocks | 1 |
+ — — — — — — — — — — — — -+ — — — — -+
8 rows in set (0.01 sec)