PHP分库分表实战指南：从路由设计到分布式事务避坑

干到一定年限的PHP后端，基本都会撞上分库分表这堵墙。我印象很深，当时负责的订单表从几百万行涨到几千万行的时候，一次简单的联表查询都能把数据库CPU拉到报警线，慢查询日志里全是全表扫描，连接数一上来直接拖垮整个服务。分库分表是个复杂的系统工程，光知道“把表拆开”远远不够，怎么拆、按什么键拆、拆完怎么查、事务怎么保证、数据怎么迁移，每一步都有坑。这篇内容就是把我这些年做PHP分库分表的思路、方案选型、落地细节和踩坑记录完整整理一遍，适合正在被大表问题折磨、或者项目已经发展到必须提前规划数据架构的同行参考。

1. 什么时候才该动分库分表

1.1 单库单表不是不行，是上限太低

先泼一盆冷水：分库分表不是技术炫技，更不是上线就加分，除非万不得已，我不会建议团队一上来就搞分库分表。为什么？因为分库分表会引入分布式事务、跨库查询、分布式主键、数据迁移等一系列复杂问题，架构复杂度会成倍上升，开发效率、排障效率都会受影响。

那什么时候才算“万不得已”？我一般看几个硬性指标：

• 单表行数超过2000万行，并且还在持续增长，日常查询明显变慢。MySQL的B+树在千万级数据量下索引深度可能到3到4层，理论还能用，但随机IO和缓存命中率会很难看。
• 单库的存储空间逼近物理磁盘或云盘容量上限，备份恢复时间长得不可接受。一次全量备份动辄两三个小时，数据库宕机后恢复同样慢，RTO根本兜不住。
• 写入QPS长期在高位徘徊，单库的写入吞吐已经到瓶颈。单个MySQL实例的写TPS一般在几千到一两万，超过这个量，锁竞争、redo log写入压力都会让延迟变得极不稳定。
• 连接数紧张。PHP-FPM每个请求通常会占用一个数据库连接，高峰期的连接数很容易把max_connections打爆。

如果你的业务还没到这些阶段，我建议先做这些事：加缓存（Redis扛读）、做读写分离（主库写、从库读）、优化慢SQL、把大字段拆到扩展表、定期归档冷数据。这套组合拳打下来，很大概率能再撑一两年。

1.2 分库分表的演进路径是分阶段走的

很多人一说分库分表就想着一步到位，实际上正确的做法是分阶段演进。我经历过的项目大多是这个路径：

第一步，单库单表，扛到扛不住了再说。第二步，加Redis缓存热点数据，这个收益最大，成本最低。第三步，做读写分离，主库只负责写，从库分担读流量。第四步，垂直拆分，按业务模块把不同功能的表拆到不同库，比如订单库、用户库、商品库分开。第五步，才是水平拆分，把同一张表的数据按某个规则散落到多个库多张表里。

顺序很重要。前四步如果都做到位了还不够，才轮到真正意义上的水平分库分表。水平拆分之所以放到最后，是因为它对外部系统影响最大，查询逻辑、事务边界、统计数据全要改，一旦上线就很难回退。我自己的经验是，研发团队最好先对业务增长做出合理预估，提前半年到一年做技术预研和方案设计，不要等到数据库真的被打爆了才临时抱佛脚。

1.3 分库分表能解决什么问题，同时带来什么问题

分库分表解决的核心问题有两个：一是数据存储容量的横向扩展，二是写入吞吐的横向扩展。原来单机物理资源有上限，现在把数据散到多台机器上，理论上容量和吞吐都能随节点数量线性增长。

但它带来的一系列新问题也很实际：

• 原来一条SQL就能搞定的事，现在要路由到正确的库表去查。
• 原来单库内的事务，现在跨库就没法用数据库本地事务保证ACID。
• 原来可以随便join的表，现在可能在两个不同的数据库实例上。
• 原来靠AUTO_INCREMENT自增主键，拆分后多个库同时生成自增ID一定会冲突。
• 原来备份、扩容都是单机操作，现在需要考虑数据在新老集群之间迁移。

这些问题不是纸面上的理论，都是实际开发中必须一个个啃下来的硬骨头。下面我按照自身经验，从方案选型到落地实现，把核心方法论和PHP侧的实操方案完整展开。

2. 分库分表的方案选型：垂直与水平到底怎么选

2.1 垂直拆分：按业务边界切分

垂直拆分有两种理解，一种是把不同业务表拆分到不同库，比如用户相关放user库，订单相关放order库，商品相关放product库。另一种是表内垂直拆分，把一张表里的字段按使用频率拆成多张表，比如把常用的基础字段放主表，把不常用的文本内容、扩展属性放到明细表。

垂直拆分的优势在于实现相对简单，业务边界清晰，各个团队可以各管一摊。比如电商系统里，订单团队只需要关注order库的表结构，不用频繁跟用户表、商品表产生耦合。缺点是如果业务之间天然存在强关联（比如下单需要同时操作用户余额和订单数据），拆分后跨库join就麻烦了，只能靠应用层做数据聚合或者引入中间层。

我自己在做垂直拆分的时候，最看重的不是“表拆得多干净”，而是“业务事务边界能不能闭环”。如果一笔核心业务操作要跨三个库才能完成事务，那这个垂直拆分可能就是失败的，不如把强关联的表放在一起。

2.2 水平拆分：按数据行切分

水平拆分是把同一张表的数据按一定规则散落到多个结构相同的表（或库）中。订单表order拆成order_0、order_1、order_2……每个表只存一部分数据，合起来才是完整数据集。

水平拆分的核心难点有两个：分片键（Sharding Key）的选择和分片算法的确定。

分片键的选择是重中之重，我见过太多项目在这上面翻车。原则很简单：选业务查询中最常见、最稳定的过滤条件作为分片键。以订单场景为例，绝大多数查询都是“查某用户的订单列表”，所以用user_id做分片键最合理。以站内消息为例，查询基本围绕接收人展开，那就用receiver_id。以流水日志为例，查询经常按时间范围展开，那就可以用时间维度取模或按月份分表。

这里多提一句，分片键一旦定下来，所有不带分片键的查询都会被路由到所有分片，然后聚合结果，这在数据量大的情况下基本等同于灾难。所以设计阶段就要想清楚：核心业务的查询路径是什么？最常用的查询条件是什么？选定了某个分片键，就必须接受“查其他维度比较痛苦”这个代价，要么做索引表（把其他维度映射到分片键），要么引入搜索引擎做二级索引。

2.3 分片算法横向对比

常见的分片算法有四种：取模、范围、一致性哈希、映射表。

• 取模分片：分片键的哈希值对分片数取模，比如user_id % 16，落到16张表中的一张。实现最简单，但对分片数变化非常敏感，扩容时数据迁移量很大，比如从16个分片扩到32个分片，几乎一半的数据都要重新分布。
• 范围分片：按某个字段的区间切分，比如2024年的订单放order_2024，2025年的放order_2025，或者按主键范围1到1000万一张表。实现也很简单，扩容友好，但从数据分布的角度说，热点问题严重——近期的数据永远集中在一个分片上，写入压力没被真正分散。
• 一致性哈希：把分片键哈希到一个环上，每个物理节点负责环上的一段区间。Aloha一致性哈希的好处是扩容时只需要迁移部分数据，但实现复杂度高，而且要搭配虚拟节点来解决数据倾斜问题。
• 映射表：单独维护一张分片规则表，记录分片键到物理分片的对应关系。灵活但是多一次查询开销，而且映射表自身可能会成为瓶颈。

我用一个表格总结一下，方便对照选型：

从我实际踩坑的经验看，中小团队的首选方案是“取模+远期规划好分片数”。你提前想清楚这个表三年后会涨到多少数据量，一次性把分片数定死，比如直接定64或128个分片，后面基本不用扩容。取模虽然扩容麻烦，但只要分片数规划够大，这个缺点是可以规避的。一致性哈希听起来很美，但真正需要动态扩容的业务其实很少，性价比不一定高。

3. PHP侧的分库分表落地实操

3.1 架构层面先想清楚，代码层面才不慌

在PHP项目里实现分库分表，市面上没有像Java那边Spring生态那么成熟统一的方案，更多时候需要自己搭一套轻量级路由。我的习惯是把数据库访问单独放到一个DAO层（Data Access Object），业务代码不直接写SQL去查库，而是通过DAO层的方法去读写，分库分表的路由规则就集中在这个DAO层里维护。

这样设计的好处很明显：如果哪天分片规则变了，只需要改DAO层，业务代码不用动。如果你把SQL散落在Controller或者Service里，有一天想从按用户ID分片改成按订单ID分片，那就等着哭吧。我在之前的项目里专门做过一次大规模重构，把散落各处的SQL收拢到DAO层，大概花了三周时间，改了几百个文件，但效果立竿见影——后来加分片路由规则时，改动量控制在了一个很小的范围。

3.2 一个轻量级分库分表路由实现

假设我们的需求是：订单表order按user_id取模分成16个库、每库1张表，库名order_db_0到order_db_15。这里我写一个简单但完整的PHP类，演示路由核心逻辑：

php复制<?php

class OrderShardingRouter
{
    private const DB_COUNT = 16;

    private array $connections = [];

    public function getConnectionByUserId(int $userId): PDO
    {
        $dbIndex = $userId % self::DB_COUNT;
        $dbName = 'order_db_' . $dbIndex;

        if (!isset($this->connections[$dbIndex])) {
            $this->connections[$dbIndex] = new PDO(
                sprintf(
                    'mysql:host=127.0.0.1;port=3306;dbname=%s;charset=utf8mb4',
                    $dbName
                ),
                getenv('DB_USER'),
                getenv('DB_PASS'),
                [
                    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
                    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
                    PDO::ATTR_PERSISTENT => true,
                ]
            );
        }

        return $this->connections[$dbIndex];
    }

    public function getTableName(int $userId): string
    {
        // 这里也可以把表也分出去，比如每个库16张表，根据另一层取模路由
        return 'order';
    }
    
    public function queryOrdersByUserId(int $userId): array
    {
        $pdo = $this->getConnectionByUserId($userId);
        $table = $this->getTableName($userId);

        $stmt = $pdo->prepare(
            "SELECT * FROM `{$table}` WHERE user_id = :user_id ORDER BY created_at DESC LIMIT 20"
        );
        $stmt->execute(['user_id' => $userId]);

        return $stmt->fetchAll();
    }
}

上面的代码只是演示核心路由思路，实际生产环境还要做连接池管理、慢查询日志、发布灰度等。有一点要重点提醒：PDO::ATTR_PERSISTENT（长连接）在PHP-FPM环境下需要谨慎使用，如果打开了长连接，而后端MySQL做了主从切换或者连接被MySQL服务端断开，客户端可能拿到的是一个已失效的连接，很多诡异的问题就是这么来的。我的做法是开启长连接但加一个“重连检测”，执行SQL前先ping一下，失效就重连。

3.3 分库分表后的中间层选择

除了自研路由，市面上也有现成的中间件方案可选，比如Apache ShardingSphere、MyCat、Vitess等。这些中间件对Java生态支持比较完善，对PHP的支持相对弱一些。ShardingSphere的JDBC模式在PHP里没法直接用，它主要面向Java语言；Proxy模式则是部署一个独立的代理层，PHP通过MySQL协议连上去，SQL由代理层解析和路由，这个PHP是可以使用的，但会增加一层网络开销和运维成本。

我个人的建议是：如果你的团队PHP经验丰富而Java中间件运维能力不足，自研一个轻量级路由可能是更务实的做法。分片逻辑本质上就是一个确定性的函数：根据分片键算出一个整数，再映射到库和表，这个逻辑不复杂，自己维护反而更灵活。如果你的团队有专门的基础设施团队，能维护好ShardingSphere Proxy或者MyCat，那用中间件也能省不少事，这条路更适合大团队、多语言接入的场景。

还有一点，MySQL 8.0之后官方也有分区表（Partitioning）的能力，单表分区在某些场景下可以用很小的代价改善查询和维护体验。但要注意，分区表在物理存储层面可以分散IO，但不解决写入吞吐和连接数瓶颈，因为数据还是在同一个MySQL实例里。分库分表和分区表不是替代关系，是不同层面的手段，不要搞混。

3.4 分布式全局ID生成方案

分库分表之后，数据库自增ID就不能用了，因为多个分片各自生成的自增ID必然重复。全局唯一ID的生成方案我实际用过的主要有以下几种：

• UUID：最简单，PHP里直接bin2hex(random_bytes(16))生成一个，全局唯一，无序，但作为主键插入B+树时会产生大量随机IO，性能不好，而且存储占空间大。适合日志、文件记录等对顺序不敏感的场景。
• 雪花算法（Snowflake）：64位整数，由时间戳、机器ID、序列号组成，趋势递增、全局唯一。这是我最推荐的主键方案，既能保证全局唯一，又因为趋势递增，对MySQL聚簇索引比较友好。
• Redis自增：用一个Redis INCR命令生成连续自增ID，简单有效，但会导致Redis成为单点，而且增加了一次网络IO。

雪花算法的PHP实现网上很多，核心就几行代码，我用一个简化版本演示：

php复制<?php

class SnowflakeIdGenerator
{
    private int $workerId;
    private int $lastTimestamp = 0;
    private int $sequence = 0;

    private const WORKER_ID_BITS = 5;
    private const SEQUENCE_BITS = 12;
    private const EPOCH = 1609459200000; // 2021-01-01 00:00:00 UTC

    public function __construct(int $workerId)
    {
        $this->workerId = $workerId;
    }

    public function nextId(): int
    {
        $timestamp = $this->getCurrentTimestamp();

        if ($timestamp < $this->lastTimestamp) {
            throw new RuntimeException('Clock moved backwards');
        }

        if ($timestamp === $this->lastTimestamp) {
            $this->sequence = ($this->sequence + 1) & ((1 << self::SEQUENCE_BITS) - 1);
            if ($this->sequence === 0) {
                $timestamp = $this->waitForNextTimestamp($this->lastTimestamp);
            }
        } else {
            $this->sequence = 0;
        }

        $this->lastTimestamp = $timestamp;

        return (($timestamp - self::EPOCH) << (self::WORKER_ID_BITS + self::SEQUENCE_BITS))
            | ($this->workerId << self::SEQUENCE_BITS)
            | $this->sequence;
    }

    private function getCurrentTimestamp(): int
    {
        return (int) floor(microtime(true) * 1000);
    }

    private function waitForNextTimestamp(int $lastTimestamp): int
    {
        $timestamp = $this->getCurrentTimestamp();
        while ($timestamp <= $lastTimestamp) {
            $timestamp = $this->getCurrentTimestamp();
        }
        return $timestamp;
    }
}

实际部署时，workerId就是各个PHP-FPM节点的编号，通过环境变量或YAML配置文件注入。如果同一台机器上跑多个PHP-FPM池，注意每个池配置不同的workerId，否则极端并发下可能出现重复ID。

3.5 分页、跨库Join与聚合查询策略

分库分表之后，原来最普通的SELECT * FROM order WHERE user_id = 123 LIMIT 10 OFFSET 20就变成了一件需要精细处理的事。如果查询条件是分片键本身，那还好办，直接路由到对应分片执行，和单库查询没区别。但如果查询条件不是分片键，就得把请求广播到所有分片，然后做数据归并，这就要命了。

跨分片分页是其中最大的坑。如果是ORDER BY created_at DESC LIMIT 10 OFFSET 20，在只有一个分片时，数据库只需要扫到第30条就返回了。但跨16个分片时，每个分片都要把各自的第30条之前的数据都查出来，然后内存里排序再取前10条。OFFSET越大，扫描的数据越多，性能灾难。

解决方案我常用的有三种：

第一，禁止跨分片深分页，产品上改成“加载更多”或者基于游标的分页方式，比如WHERE created_at < :last_created_at ORDER BY created_at DESC LIMIT 10，这种方式天然天然地能精确路由到正确的分片，性能稳定。这是最推荐的方案，大部分C端业务都能接受。

第二，对非分片键的查询提前建立索引表。比如用户经常按订单号查订单，而订单表是按user_id分片的，那可以建一张order_no到user_id的映射表，查的时候先按订单号查出user_id，再按user_id路由到对应分片查订单详情。这里要把映射表自身当成一个单库热点来保护，可以加缓存。

第三，引入搜索引擎。对全文搜索、复杂条件筛选这类场景，把数据同步到Elasticsearch，由ES做检索和聚合，查出主键ID后回表到各个分片拉取数据。这个方案运维成本高一些，但很实用，尤其是后台运营系统经常需要多条件组合筛选的时候。

至于跨库Join，我的态度很明确：能避免就避免。实际工程中我采取三种策略来绕开跨库Join——冗余字段（在查询方表里冗余需要的字段）、宽表（用一张大宽表同步多张表的数据，专门供查询使用）、多次查询后在PHP内存中做数据组装。比如查订单列表时同时需要商品名称，我可以在订单表里冗余一个商品名称快照字段，下单时写入，就可以避免联表查商品表。这种“以空间换时间”的做法在分库分表场景下非常常见。

4. 分库分表后的分布式事务，怎么解决才踏实

4.1 本地事务失效，可靠性怎么办

分库分表后最让人头疼的问题之一就是事务。以前在单库中，一个事务里可以随意更新订单表、库存表、用户余额表，要么全部成功，要么全部回滚。但拆库之后，这些表可能分布在不同的MySQL实例上，本地事务就管不住了。

这里需要明确一个原则：分布式系统里不存在银弹，不可能同时保证强一致、高可用和低延迟。所以实际工程中，大家普遍放弃强一致，转而追求最终一致性。只有在极少数对一致性要求极高的场景下，才会用事务协调器做强一致方案。

4.2 实用的最终一致性方案

我最常用的方案有两种。

第一种是本地消息表（事务消息）方案。把“业务操作”和“发送消息”放在同一个本地事务中，比如在订单库中，开启一个事务同时写入订单表和消息表，事务提交后，再由一个异步worker扫描消息表，把需要通知下游的数据发送到消息队列中，下游消费者监听队列去做后续处理。如果消息发送失败，worker会重试，保证消息最终被投递出去。

这里我提一个非常关键、容易踩坑的点：PHP中通过事务操作消息表时，务必要确保事务提交后再发消息，不要出现在事务内直接调用MQ发送的写法。因为如果消息先发出去了，事务后来又回滚了，下游消费者已经收到消息开始处理，就会产生脏数据。本地消息表方案的精髓就在于“业务表和消息表同库同事务”，所以设计人员要仔细推敲分库边界，确保这笔操作的所有本地数据都在同一个库里。

第二种是消息队列的可靠事件方案。业务操作成功提交后，把事件写入Redis或MQ，消费者做补偿性操作。这种方案实现上更简单，但一致性的保证力度不如本地消息表，需要更完善的重试和告警机制。适合对数据一致性要求不那么高、可以容忍短时间不一致的业务。

4.3 别轻易尝试的方案

有人会想到用两阶段提交（2PC）来保证分布式事务的强一致。Java生态里有Atomikos、Seata这类框架，PHP这边要实现完整的2PC需要自己写prepare、commit、rollback协调逻辑，复杂度和风险都很高。除非公司自研中间件能力很强，否则我建议不要在产品代码里自研2PC，一个网络超时或者进程崩溃就会让事务卡在中间状态，很难排查。

还有TCC（Try-Confirm-Cancel）模式，本质上需要业务方把每个操作拆成预留、确认、取消三步，开发量很大，而且对资源锁定有时间窗口，用户体验也会受影响。在PHP业务中，如果没有框架层面的强支持，我一般不会推荐TCC。

我有一个经验总结：在做分库分表之前，花时间梳理清楚哪些业务操作可以接受最终一致性、哪些必须强一致，把必须强一致的业务尽量通过合理的数据分片设计控制在同一个库内。比如设计分片时，让“用户下的订单”与“用户的余额变动”都按user_id落在同一个库里，这样用户下单扣余额的操作可以在单库内用本地事务解决。分库分表不是把事务打散，而是通过合理的数据分布，尽可能减少跨库事务的边界。

5. 分库分表实施中的常见问题排查与避坑

5.1 数据倾斜：分片键选错引发的“一库独大”

分片键设计不好最典型的表现就是数据倾斜。比如用商家的ID做分片键，有的头部商家有上千万订单，有的小商家只有几十单，取模之后头部商家的数据还是集中在少数几个分片，这几个分片的存储和写入压力成了新的瓶颈。我之前接手过一个报表系统，按用户ID取模分片，结果有一批机器人注册的大量垃圾账号，把数据分布全打歪了，某几个库的磁盘占用是其他库的好几倍。

遇到这种情况，排查思路是先统计每个分片的数据量，用一条SELECT COUNT(*)分别跑一下，看分布是否均匀。然后看有没有“热点用户”或“热点商家”，如果有，可以对热点数据单独拆分或做二次分片。更根本的做法是选一个“粒度更细”的key，比如把订单的分片键从user_id改成order_id，因为order_id的取值更离散，分布会更均匀——但代价是按用户查订单时要先走索引表。

5.2 分片键隐藏陷阱：查询不走分片键直接压垮数据库

这是分库分表场景下最普遍的线上事故。比如订单表按user_id分片，前端页面展示订单详情时需要根据订单号order_no直接查，开发图省事直接在代码里用了WHERE order_no = ?，没带user_id，这条SQL被路由到了所有16个分片去执行，每个分片都全表扫一遍，可能直接把数据库实例全打挂。

应对措施有两个层面。技术层面：在订单表中额外建立一个order_no到user_id映射的索引表，查询先走索引表，拿到user_id再精确路由。组织层面：在DAO层的路由函数里加一个显式检测，如果调用方没有传分片键就直接抛异常，从代码层面杜绝失误。对分库分表系统，我强烈建议把“必须带分片键”作为代码review的硬性规则。

5.3 数据迁移和扩缩容：如何做到不停机切换

老系统从单库迁移到分库分表，或者已经分库分表的系统需要扩容，这个过程非常容易出事故。我经历过的比较平稳的迁移思路是“双写+校验+切换”，步骤如下：

第一步，部署新分片集群，保持空的库表结构。

第二步，应用层开启双写，业务数据既写旧库，也按新分片规则写入新库。这里可以异步进行，比如监听MySQL binlog，把增量数据同步到新库，应用代码不需要双写，侵入性更小。

第三步，全量同步历史数据到新库，边同步边校验，对账工具定期对比新旧库数据条数和指纹，发现不一致就重放对应时间段的binlog。

第四步，等新库数据追平，选择一个流量低峰期，把读流量先切到新库，观察一段时间没有异常，再把写流量切到新库，最后下线旧库。

这个过程中最忌讳的是：没有回退方案就直接全流量切换。每次迁移我都要求团队必须提前准备好一键回滚脚本，一旦新库出现明显异常，能在5分钟内把流量切回旧库。因为分布式系统的问题往往会在灰度阶段才暴露出来，流量切换必须有应急预案。

5.4 分片后的运维与监控

分库分表之后，日常运维的复杂度也上来了。原来的主从监控、慢查询分析、容量规划都变成了多实例的。我建议至少把以下几项做进监控体系：

• 每个分片的连接数、CPU、磁盘IO、延迟，单独告警，避免某个分片出问题被整体大盘掩盖。
• 每条SQL的路由日志，确保没有“广播扫全库”的慢查询SQL出现在线上。很多路由层框架会打印sharding日志，要充分利用起来。
• 分片间数据量分布，定时统计，超过阈值提醒，防止数据倾斜慢慢恶化。
• 全局主键生成器的时钟回拨告警，尤其是部署在虚拟化环境里，NTP时间同步偶尔会跳变，雪花算法对时钟很敏感。

监控做得好不好，决定了分库分表系统在线上跑得是否安心。我的做法是先把分片维度的监控数据接入统一监控大盘，然后定期做容量压测，模拟某个分片故障看整体表现。这一步能提前暴露不少问题，比如连接池不够用、某些分片查询延迟特别高等。

6. PHP项目分库分表实战心得补充分享

最后再分享几点我在实际项目中得出的体会。

第一，分库分表和PHP框架的ORM结合并不容易，尤其是Laravel的Eloquent、ThinkPHP的模型关联，它们天然假设你在单库里做表关联。如果你用了ORM的关联查询，分片后会很痛苦。我的建议是，分库分表的路由逻辑放在仓储层或DAO层，业务模型尽量不再直接使用ORM跨表关联功能，而是手动组装数据。这会让某些熟悉ORM的开发觉得繁琐，但换来的是可控性和可维护性。

第二，缓存和分库分表要搭配使用，而不是互相替代。分库分表解决的是写和存储的扩展，缓存解决的是读的高并发。两者可以叠加，比如在DAO层先查Redis，命中了就不走数据库，没命中再去对应分片查询并回填缓存。我测试过，引入缓存后，分库分表系统的整体吞吐可以再上一个台阶。但要特别留意缓存穿透和缓存击穿的问题，分库后数据量更大，一旦缓存失效，大量请求同时打到分片，很容易把数据库击穿。

第三，不要为了追求“完美架构”而过度设计。如果一个项目数据量在未来两年内预计不超过500万行，单库单表加缓存完全够用，分库分表就没必要做。过度设计会白白浪费开发资源，还引入了大量不必要的运维和排查成本。我做技术决策时一向坚持一个原则：架构必须为业务服务，而不是业务为架构买单。分库分表是一个强有力的工具，但它不是万能药，用在合适的时机、合适的场景下，才能真正发挥价值。