数据库分库分表存储百万级跨境商品数据
数据库分库分表是解决百万级跨境商品数据存储瓶颈的常用手段。
核心思路是将一张超大的商品表拆成多个较小的物理表,分散写入和查询压力。
本文从零开始,告诉你什么时候该分、怎么分、用什么工具,并提供可直接执行的步骤,即使是新手也能跟着完成。
什么情况下需要分库分表
当你的跨境商品数据量达到百万级别,并且出现以下现象时,就该考虑分库分表了:
- 单表查询越来越慢,即使加了索引也经常超过1秒。
- 商品更新、删除操作导致锁表时间变长。
- 数据库磁盘或内存压力持续升高。
- 业务增长稳定,未来数据量还会继续翻倍。
如果当前单表数据只有几十万条且性能正常,不要提前做分库分表,否则会增加开发和维护成本。
分库分表前的准备工作
- 确认数据库版本:MySQL 5.7 及以上版本对分表支持更好,建议使用 8.0。
- 选择分片键:跨境商品最常用的分片键是
category_id(商品类别)或seller_id(店铺ID)。分片键要满足查询频率高、数据分布均匀的特点。 - 评估数据量:假设总商品数 200 万,按 10 个类别分表,每个表 20 万行,性能明显提升。
- 准备中间件或纯 SQL 方案:
- 中间件方案:ShardingSphere、Mycat 等,适合跨库查询和分布式事务。
- 纯 SQL 方案:在应用层写分表逻辑,手动拼接表名,适合简单场景。
本文演示纯 SQL 方案,因为零基础入门更容易理解。
手把手实现商品分库分表
假设你的商品表结构如下:
CREATE TABLE `products` (
`id` bigint NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`category_id` int NOT NULL,
`price` decimal(10,2),
`stock` int,
PRIMARY KEY (`id`)
);
现在我们要将其按 category_id 分表,每个类别一张表,表名格式 products_${category_id}。
第一步:创建分表
先批量创建 10 张分表(假设 category_id 从 1 到 10):
CREATE TABLE products_1 LIKE products;
CREATE TABLE products_2 LIKE products;
-- ... 直到 products_10
第二步:迁移数据
将原表数据按类别插入到对应分表:
INSERT INTO products_1 SELECT * FROM products WHERE category_id = 1;
INSERT INTO products_2 SELECT * FROM products WHERE category_id = 2;
-- 以此类推
第三步:修改应用查询逻辑
在代码中,每次查询前根据 category_id 拼接表名,例如:
def get_products(category_id):
table_name = f'products_{category_id}'
sql = f'SELECT * FROM {table_name} WHERE ...'
# 执行 SQL
第四步:如果跨类别查询怎么办?
使用 UNION ALL 查询所有分表,但前提是表结构完全一致:
SELECT * FROM products_1 WHERE name LIKE '%手机%'
UNION ALL
SELECT * FROM products_2 WHERE name LIKE '%手机%';
如果跨类查询频繁,建议升级为中间件方案,中间件会自动路由。
高频问题与避坑指南
Q1:分表后如何保证自增主键全局唯一?
A:使用雪花算法(Snowflake)或数据库分段生成。简单做法是在应用层用 Redis 生成唯一 ID。
Q2:分表后还能做排序分页吗?
A:可以,但需要先查各分表的分页数据再合并。例如查询第 2 页(每页 20 条),先对每个分表查询前 40 条,然后在应用层排序取第 21-40 条。数据量越大效率越低,建议不要跨分表排序,或者使用中间件。
Q3:分库分表后事务怎么处理?
A:纯 SQL 方案无法保证跨表事务一致性。如果业务要求强事务,必须使用中间件(如 ShardingSphere 支持分布式事务),或者改用数据库自带的 XA 事务(性能较差)。
Q4:如果后续新增种类怎么办?
A:预留足够的初始分表数,比如按最高可能类别数创建 100 张空表。新增类别只需在应用层添加映射,无需迁移数据。
关键避坑点
- 分片键一旦确定,不要轻易修改,否则需要全量迁移。
- 一定要在低峰期执行数据迁移,并提前备份。
- 不要在分表上使用外键,会严重拖慢性能。
- 如果使用云服务器(例如泽御云提供的 MySQL 实例),注意配置连接池和慢查询日志,方便排查。
验证存储与查询效果
- 查看各分表数据行数:
SELECT COUNT(*) FROM products_1;
SELECT COUNT(*) FROM products_2;
各表行数应大致均衡。
- 测试查询性能:
SELECT * FROM products_1 WHERE id = 123; -- 之前单表慢查询现在应 <10ms
- 监控数据库 CPU 和 IO:压力明显下降说明分表生效。
- 在应用层编写测试用例,确保增删改查各分表都正常工作。
如果你正在处理数据库分库分表存储百万级跨境商品数据,建议先按本文步骤完整执行,再根据自己的环境做微调;
遇到异常时优先回看避坑和高频问题部分。
长期运行后建议使用中间件或云数据库的分库分表服务,进一步降低维护复杂度。