MySQL 数据量达到千万级以后，SaaS 数据库应该考虑哪些变化

对于SaaS系统来说，MySQL单表数据达到千万级以后，真正需要面对的并不是一个简单的“数据量太大”问题，而是数据库开始暴露出查询、索引、写入、锁竞争、存储增长、租户隔离和数据生命周期等一系列架构问题。千万级数据本身并不意味着MySQL已经无法继续使用，也没有一条规则规定达到1000万行就必须分库分表。设计良好的表结构、合理的索引和足够的硬件资源，完全可能支撑更大的数据规模。真正应该触发架构调整的，是实际工作负载已经出现瓶颈。

第一步应该是确认数据库究竟慢在哪里，而不是看到千万级数据就开始设计分片。对于慢查询，EXPLAIN和EXPLAIN ANALYZE比单纯查看数据量更加重要。需要观察访问路径、实际扫描行数、过滤效率、排序和临时表、回表次数以及执行时间。EXPLAIN中的type出现range并不代表查询有问题，index也不意味着一定需要优化。判断一个查询是否合理，关键是执行计划是否符合查询条件和索引设计，以及实际读取了多少数据。

SaaS系统最常见的问题之一，是业务查询没有围绕实际访问模式设计索引。例如大量请求都是“某个tenant_id最近一段时间的数据”，那么tenant_id、时间字段以及其他高选择性条件之间的组合关系，就应该根据真实SQL设计复合索引。索引列的顺序不能靠固定模板决定，需要结合WHERE、JOIN、ORDER BY以及数据分布判断。索引也不是越多越好，但“单表最多5个索引”同样不是MySQL规则。一个写入频繁的表可能因为多个核心查询而需要多个索引，而另一个表可能几个索引就足够。真正需要关注的是索引带来的查询收益，以及INSERT、UPDATE、DELETE时额外产生的维护成本。

随着数据量增加，主键设计也越来越重要。InnoDB表通常应该认真考虑主键的数据类型、增长方式以及二级索引成本。过大的主键会间接增加二级索引占用的空间，因为InnoDB二级索引记录中需要保存主键值。对于高写入系统，还需要观察页分裂、随机写入、Buffer Pool命中情况以及磁盘I/O，而不能只盯着CPU使用率。

事务和锁竞争往往比“表里有多少行”更容易直接造成线上故障。SaaS系统中的订单、库存、账户余额、配额等业务通常存在并发更新，需要分析事务持续时间、锁等待、死锁以及长事务对InnoDB历史版本清理产生的影响。REPEATABLE READ和READ COMMITTED应该根据业务一致性要求选择，而不是因为数据量增加就机械切换。

SELECT ... FOR UPDATE也不能当成通用的并发优化手段。它的作用是建立必要的锁保护，但如果事务持锁时间过长，反而可能放大锁竞争。对于冲突概率较低的更新场景，可以考虑version字段等乐观并发控制方式。对于冲突严重的业务，则需要结合事务边界、索引设计和更新顺序一起处理。

UNIQUE约束也不应该为了所谓的性能而简单删除。比如一个租户内用户名、订单号或外部业务编号必须唯一，如果只在PHP应用层先SELECT检查再INSERT，在高并发环境下两个请求完全可能同时通过检查，最终产生重复数据。数据库约束承担的是最终一致性和数据正确性保障。真正需要优化的是索引结构、事务范围以及冲突处理方式。

当单实例经过SQL和索引优化、硬件升级、读写分离、缓存以及数据归档之后仍然无法满足容量或吞吐要求，才需要认真考虑分库分表。分片首先是业务边界问题，其次才是数据库技术问题。SaaS系统比较自然的分片键通常是tenant_id，但并不是所有系统都适合直接按照租户切分。如果存在少数超大型租户，它们可能形成明显的数据倾斜，一个租户就能占据某个分片的大部分资源。

因此，在设计分片方案之前，需要回答几个实际问题：单库当前QPS和TPS是多少，数据增长速度是多少，最大的租户占多少数据，热点查询集中在哪里，单实例磁盘和I/O是否已经成为瓶颈，以及未来两三年的增长是否会突破当前架构的容量边界。只有这些问题得到答案，才能判断究竟需要分表、分库，还是仅仅优化现有实例。

分片以后，真正麻烦的通常不是“数据放到哪里”，而是“查询应该去哪里”。如果绝大多数业务请求都带有tenant_id，路由相对容易；如果经常按照没有分片键的条件查询，就可能产生多个分片同时查询再进行结果合并。随着分片数量增加，网络通信、结果合并和排序成本都会增加。因此，分片并不天然等于性能提升，它只是把单节点容量问题转换成了分布式数据访问问题。

跨分片业务也不意味着必须马上引入TCC或者其他分布式事务框架。很多情况下，更合理的方案是重新划分业务边界，减少跨分片强一致事务，把部分操作改成消息驱动、异步处理或者最终一致性。真正需要分布式事务的场景，应当根据业务一致性要求和失败恢复机制决定，而不是把分布式事务框架当成分片之后的标准配置。

在读压力较高的SaaS系统中，读写分离通常比直接分片更值得优先考虑。MySQL主库负责写入，通过复制将数据同步到一个或多个只读副本，再把适合的查询分配过去。不过这里必须考虑复制延迟。刚刚写入的数据如果马上从副本读取，可能暂时看不到，因此不能把所有SELECT无条件地发送到Read Replica。对于要求强一致的读取，应继续访问主库或者采用其他一致性策略。

Redis同样应该围绕真正的热点数据使用，而不是把数据库里的所有东西都缓存一遍。典型场景包括高频读取、变化相对较少、允许短时间缓存的数据。缓存设计必须考虑TTL、主动失效、缓存击穿、缓存雪崩以及数据库更新与缓存更新之间的一致性。对于库存、余额等强一致性数据，缓存只是辅助组件，不能因为加入Redis就绕过数据库事务控制。

随着SaaS业务增长，异步架构的重要性也会逐渐提高。日志、通知、Webhook、统计、邮件、搜索索引更新等并不一定需要阻塞主交易请求，可以通过消息队列交给后台消费者处理。消费者需要具备幂等能力，因为消息系统中的重复投递和重试是正常工程情况。对于大批量统计和数据处理，还可以采用批处理，避免每个用户请求都直接触发昂贵的数据库计算。

数据生命周期管理也是千万级数据库容易被忽略的一环。很多SaaS系统真正拖慢数据库的，并不是核心业务表，而是不断增长的访问日志、审计记录、操作记录、Webhook历史、统计明细和临时数据。如果这些数据永远堆在热表中，索引和Buffer Pool都会不断膨胀。可以根据业务需求建立Hot Data和Cold Data策略，把历史数据归档到专门的历史表、对象存储或分析系统。对于具有明显时间范围的数据，也可以研究MySQL分区表，但分区不是万能的查询加速器，必须确认查询模式能够真正利用分区裁剪。

多租户SaaS还需要特别关注tenant_id带来的数据隔离问题。要求每条查询都带tenant_id只是第一层防线，不能把安全性完全寄托在开发人员“记得写WHERE tenant_id”的习惯上。Repository、ORM、数据访问层、后台任务、缓存Key、消息消费者都应该保持租户上下文，否则一个遗漏tenant_id的后台查询就可能产生跨租户数据泄露。

如果系统未来需要按tenant_id进行分片，那么从早期开始让核心业务表具有明确的租户归属，会为后续架构演进降低成本。但也不能为了未来分片而给所有表机械添加字段。真正重要的是建立清晰的数据归属关系，让业务对象能够明确判断属于哪个租户。

数据库监控则应该从“数据库现在还能不能跑”升级到“数据库什么时候会出现容量和性能拐点”。除了CPU、内存和磁盘空间，还应该持续观察QPS、TPS、P95和P99延迟、慢查询、Buffer Pool、磁盘I/O、Redo Log、锁等待、死锁、连接数、事务持续时间、复制延迟以及数据增长速度。对于大型SaaS系统，单纯看平均响应时间很容易掩盖少数慢请求，因此P95和P99更加有参考价值。

安全方面也必须纠正一个常见错误：用户密码不应该使用AES这种可逆加密方式保存。密码验证应该使用专门的密码哈希算法，例如Argon2id、bcrypt或scrypt，并配合合理的参数配置。AES适用于确实需要恢复原文的数据加密场景，例如某些需要重新读取的敏感业务数据，但密钥管理同样重要。SQL注入则应该通过参数化查询、预编译语句以及严格的数据访问层控制来防御；越权问题不能只依赖前端传来的tenant_id，而应该由服务器端根据认证身份确定数据访问范围。

对于PHP+MySQL的SaaS系统，架构演进没有必要一开始就奔着微服务、分库分表、Redis集群和分布式事务去。更加现实的路线通常是先把SQL和索引做好，然后解决事务和锁问题，再根据实际读压力考虑只读副本；之后针对明确的热点引入缓存，把日志、通知、Webhook和统计等非核心操作异步化，同时建立历史数据归档机制。当单实例的容量、吞吐或故障域确实成为瓶颈时，再进入分库分表阶段。

对于报表和分析业务，也不应该让生产MySQL承担所有计算。如果复杂聚合查询已经明显影响在线交易，可以考虑把分析数据同步到专门的分析数据库或数据仓库，让OLTP系统负责交易，让分析系统负责大量扫描和聚合。这样解决的不是“千万级数据太大”，而是避免在线交易和分析查询争夺同一套数据库资源。

所以，MySQL达到千万级以后，最应该发生的变化不是立即把数据库切成几十个库，而是从“能用就行”的数据库管理方式，转向基于工作负载、数据生命周期和业务边界的工程化管理。千万级数据应该成为一次数据库健康检查的信号，而不是触发分库分表的自动开关。真正成熟的SaaS架构，是能够知道什么时候应该优化SQL，什么时候应该增加索引，什么时候应该增加只读副本，什么时候应该使用缓存和消息队列，又在什么情况下确实已经到了必须分片的阶段。

对于长期运行的SaaS系统，最昂贵的往往不是多买一台数据库服务器，而是在没有确认瓶颈之前就引入一套复杂的分布式架构。数据库可以扩容，错误的分片键、跨库事务和历史数据迁移却可能成为多年遗留的工程债务。因此，最可靠的演进方式仍然是让监控数据、压力测试和真实业务负载决定下一步，而不是让“千万级”这个数字替开发团队做架构决策。