一次复杂的分布式数据库性能问题排查与解决

原创

七条猫

发布于 2025-08-29 20:40:05

4232

Bug 现象

在我们最近的一个项目中，使用了 MySQL 分库分表来应对订单量快速增长的问题，同时启用了读写分离以优化查询性能。然而，在某个高峰期，系统突然出现大量慢查询警告，导致部分用户无法正常下单。具体表现为：

用户提交订单时响应时间超过 5 秒。
数据库监控平台显示某些查询的执行时间异常长。
部分订单数据未能正确写入分片表。

排查步骤

Step 1：初步定位问题

通过日志分析工具（如 ELK Stack）查看后端服务的日志，发现慢查询集中在以下几个 SQL 操作：

-- 查询订单详情
SELECT * FROM orders WHERE user_id = ? AND order_time > ?;

-- 插入新订单
INSERT INTO orders (user_id, order_time, amount) VALUES (?, ?, ?);

这些操作涉及分库分表和读写分离逻辑，可能与配置不当有关。

Step 2：检查分库分表策略

我们使用 ShardingSphere-JDBC 实现了分库分表，逻辑如下：

分库规则：根据 user_id 的哈希值将数据分散到两个物理库（db_0 和 db_1）。
分表规则：在每个物理库中，按月份创建表（如 orders_202309, orders_202310）。

经过排查，发现问题出在 跨分片查询 上。例如，当用户查询其所有历史订单时，SQL 需要扫描多个分片表，导致性能下降。

Step 3：验证读写分离配置

我们的读写分离规则是：

写操作路由到主库。
读操作优先路由到从库。

但通过监控发现，部分写操作被错误地路由到了从库，造成数据一致性问题。这是由于 ShardingSphere-JDBC 的默认负载均衡策略未充分考虑事务上下文。

Step 4：深入分析慢查询原因

进一步分析慢查询日志，发现以下问题：

跨分片查询未使用覆盖索引，导致全表扫描。
部分查询缺少必要的索引，尤其是 user_id 和 order_time 组合字段。

解决方案及代码修复

1. 优化分库分表设计

为了避免频繁的跨分片查询，调整分库分表策略：

新增全局索引表：为 user_id 创建一个全局索引表，记录每笔订单所在的分片位置。
减少热点分片：引入范围分区策略，按日期范围分配数据，降低单个分片的压力。

以下是全局索引表的设计：

CREATE TABLE global_index (
    user_id BIGINT NOT NULL,
    shard_key VARCHAR(32) NOT NULL, -- 标识分片位置
    PRIMARY KEY (user_id)
);

2. 修正读写分离配置

修改 ShardingSphere-JDBC 的配置文件，确保写操作始终路由到主库，并优化读操作的负载均衡策略：

rules:
  - !SHARDING
    tables:
      orders:
        actualDataNodes: db_${0..1}.orders_${202301..202312}
        tableStrategy:
          standard:
            shardingColumn: order_time
            shardingAlgorithmName: monthly-sharding
    defaultDatabaseStrategy:
      standard:
        shardingColumn: user_id
        shardingAlgorithmName: hash-modulo
  - !READWRITE_SPLITTING
    dataSources:
      ds_master_slave:
        writeDataSourceName: master
        readDataSourceNames:
          - slave_0
          - slave_1
        loadBalancerName: round-robin

3. 添加复合索引

为订单表添加复合索引，提升查询效率：

ALTER TABLE orders ADD INDEX idx_user_order (user_id, order_time);

4. 改进慢查询日志监控

在 Spring Boot 中集成慢查询日志分析工具，定期生成报告并发送到运维团队邮箱：

@Configuration
public class SlowQueryLogConfig {

    @Bean
    public DataSource dataSource() {
        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/db_0");
        dataSource.setUsername("root");
        dataSource.setPassword("password");
        dataSource.addDataSourceProperty("slowQueryThreshold", "2000"); // 设置慢查询阈值为 2 秒
        return dataSource;
    }
}

避坑总结

问题类型	原因分析	解决方法	备注
跨分片查询性能差	缺少全局索引，频繁扫描多分片表	引入全局索引表，优化分片策略	注意维护索引表的一致性
读写分离配置错误	默认负载均衡策略未考虑事务上下文	修改配置文件，明确区分主从库角色	测试环境需模拟真实场景
缺少必要索引	查询条件未命中索引，导致全表扫描	添加复合索引，定期审查 SQL 执行计划	索引过多会影响写性能
慢查询监控不足	日志信息不直观，难以快速定位问题	集成慢查询日志分析工具，定期生成报告	关注业务高峰期的表现

总结

这次调试经历让我深刻认识到，分布式数据库的性能优化不仅依赖于合理的分库分表设计，还需要结合实际业务场景不断调整策略。通过引入全局索引、优化读写分离配置以及加强慢查询监控，我们成功解决了性能瓶颈问题，并提升了系统的稳定性。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

腾讯技术创作特训营S15#debug日志