跨境商品数据库检索慢？分表分库优化方案实战

跨境商品数据量超过千万级时，单表查询往往从几十毫秒飙升到数秒甚至超时。
直接加索引或升级硬件效果有限，核心思路是将数据拆分到多个物理表中，降低单表扫描量。
本文从实际运维角度，带零基础用户一步步落地分表分库方案。

先搞清楚瓶颈：为什么商品表查询会越来越慢

商品表通常包含SKU、标题、价格、库存、属性和多语言描述，字段多、行数大。
单表超过500万行后，即使命中索引，B+树深度增加，IO次数增多；
如果业务接入了多个国家站点的联合查询，还会出现跨索引扫描。分表分库的本质是让每次查询只操作小部分数据，减少IO和CPU开销。

方案设计：根据业务特点选择拆分策略

水平分表——最常用的做法

按商品ID取模，例如 mod(goods_id, 64) 将数据散列到64张表。
优点是数据均匀，每个分片大小可控；
缺点是跨分片聚合（如查询某品类所有商品）需要合并结果。

垂直分表——字段分离

把大字段（如详细描述、多语言JSON）拆到单独的表，主表只保留高频检索字段（ID、标题、价格、状态）。
这样单表行数不变但行宽变小，单位数据页能容纳更多行，减少IO。

分库——拆分主从或不同集群

将不同国家或区域的商品分到不同数据库实例，例如 db_us、db_de、db_jp。
业务层根据用户请求的地理信息路由到对应库，同时降低单库连接压力。

实际生产中推荐先垂直分表减小行宽，再水平分表控制单个分片行数，最后按业务区域分库实现读写分离。

实战配置：以ShardingSphere 5.x为例

安装ShardingSphere-Proxy或使用ShardingSphere-JDBC集成到Java项目。
以下给出ShardingSphere-JDBC的YAML配置片段，适用于Spring Boot项目。

# application.yml 中配置
spring:
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://192.168.1.10:3306/db0
        username: shop
        password: secret
      ds1:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://192.168.1.11:3306/db1
        username: shop
        password: secret
    rules:
      sharding:
        tables:
          goods:
            actual-data-nodes: ds$->{0..1}.goods_$->{0..31}
            database-strategy:
              standard:
                sharding-column: goods_id
                sharding-algorithm-name: db_mod
            table-strategy:
              standard:
                sharding-column: goods_id
                sharding-algorithm-name: tbl_mod
        sharding-algorithms:
          db_mod:
            type: MOD
            props:
              sharding-count: 2
          tbl_mod:
            type: MOD
            props:
              sharding-count: 32

配置说明：将goods表按goods_id取模分到2个库、每个库32张表，共64张物理表。
修改后重启应用，所有SQL自动路由。

如果使用MyCat，则在schema.xml中配置和，原理类似。

易踩的坑和解决方法

分页查询跨分片

使用 ORDER BY column LIMIT page, rows 时，
ShardingSphere需要收集所有分片的前 page + rows 条数据排序后再取出目标页，
数据量越大越慢。优化手段：
改用游标分页（带上次查询的最后ID）或限制最大偏移量。

跨分片聚合（COUNT/SUM）

每个分片独立计算，ShardingSphere再汇总，性能可接受。
但如果涉及多个聚合字段且业务频繁调用，建议建立独立的统计表或使用Elasticsearch。

全局唯一ID生成

分表后自增主键失效。
可使用雪花算法（Snowflake）生成全局ID，ShardingSphere内置了SNOWFLAKE算法。
在配置中为goods表指定主键生成策略：

key-generators:
  snowflake:
    type: SNOWFLAKE
    props:
      worker-id: 1

然后在 tables.goods下添加key-generate-strategy。

验证优化效果：从慢日志到业务响应

1. 开启慢查询日志：在MySQL中执行 SET GLOBAL slow_query_log=1; SET GLOBAL long_query_time=1;（单位秒）。
2. 对比测试：分别对单表和分表后的库执行同样查询，注意清除缓存（RESET QUERY CACHE）。
3. 业务层面：记录接口P99延迟。如果分片后延迟从3秒降到300毫秒，基本达标。
4. 监控：使用Prometheus+Grafana监控数据库连接数和慢查询次数。

如果你正在处理分表分库优化海量跨境商品数据库检索速度方案，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。