数据库是大型架构核心，下面我详解MySQ千万QPS方案@mikechen
第一阶段：单机性能极限优化
在考虑分布式之前，先要把单机的性能榨干。
在理想条件下（纯读、小表、命中缓存），单实例 MySQL：5k–2w QPS。
可以，硬件升级（垂直扩展）。
比如：换用 NVMe SSD 硬盘、增加内存（让数据尽可能留在 Buffer Pool 中）、使用高频多核 CPU。
以及，配置调优。
调整 innodb_buffer_pool_size（通常设为内存的 60%-80%）、innodb_flush_log_at_trx_commit（权衡安全与性能）。
以及，索引与 SQL 优化。
严禁全表扫描，利用覆盖索引减少回表，拆分复杂的 Join 查询。
第二阶段：读写分离
当单机压力主要来自“读”时，通过主从架构分担压力。
应用 ↓ 读写分离中间件 ↓ 主库（写） ↓ 从库1 / 从库2 / 从库N（读）
架构： 一主多从（Master-Slave），主库负责写，多个从库负责读。
中间件： 使用 ProxySQL、MyCat 或 ShardingSphere 实现读写请求的自动路由。
瓶颈： 这种方式受限于主库的写性能以及从库同步的延迟。
第三阶段：引入缓存层
这是达到千万级 QPS 的关键， 数据库不应该直接面对每秒千万次的请求。
大部分高频访问的重复数据，应由缓存消化。
技术栈： Redis 或 Memcached。
热点数据缓存： 将最频繁访问的数据放在 Redis 中，QPS 提升可达百倍。
旁路缓存： 应用先查缓存，命中则返回；未命中再查数据库并回写缓存。
效果： 能够分担 80%-90% 的读请求。
第四阶段：数据库拆分
当单库的数据量超过千万行，或者写请求达到单机瓶颈时，必须进行水平拆分。
1. 垂直拆分 (Vertical Sharding)
按业务模块将表分到不同的数据库实例。
例子： 将用户信息表、订单表、商品表分别放在不同的 DB 实例上。
2. 水平拆分 (Horizontal Sharding)
将同一张表的数据按某种规则（如 UserID 取模）分布到多个库、多个表中。
分片键 (Sharding Key)： 选择合适的 Key 非常关键，避免跨分片查询。
工具： ShardingSphere、Vitess。
mikechen睿哥
10年+一线大厂架构实战经验，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。