针对一个百万级用户的大型用户表，设计分库分表策略，并说明如何保证数据一致性和查询性能。

1) 【一句话结论】：针对百万级用户表，采用“垂直分库+水平分表（哈希+时间维度结合）”策略，通过Seata AT模式分布式事务+异步补偿机制保证数据一致性，结合Redis缓存预热（热点用户预加载+布隆过滤器防穿透），实现读写分离与动态扩容，平衡性能与一致性。

2) 【原理/概念讲解】：分库分表的核心是“拆分数据，提升系统承载能力”。垂直分库是将不同业务表（如用户表、订单表、商品表）按业务模块分散到多个数据库实例，适用于业务表数量多（>100张）、单表数据量大的场景（如电商系统中用户、订单、商品各表独立分库，避免单库因表多或数据量大导致性能瓶颈）。水平分表是将单表按行拆分为多个子表，常用策略有：哈希分表（用户ID哈希取模，均匀分布，适合动态扩容，但可能因新用户集中导致冷热数据不均）、范围分表（按用户ID范围，如0-1M、1M-2M，适合数据增长有规律的场景，扩容需迁移部分数据）、时间分表（按时间维度，如订单表按月分表，适合时间序列数据，查询按时间聚合效率高）。分片键选择需结合业务特征：用户ID哈希可能导致冷热数据分布不均（新用户集中到某分片），因此结合时间维度调整分片键（如用户ID哈希取模+注册时间范围），平衡数据分布与查询效率（例如，用户ID为123456，哈希取模得库索引0，注册时间2023-01则表索引为0，若注册时间2023-07则表索引为6，避免新用户集中到同一分片）。

3) 【对比与适用场景】：

策略类型	定义	特性	使用场景	注意点
垂直分库	按业务模块将不同表分散到多个数据库	单表数据量小，跨库操作复杂（需分布式事务支持）	业务表数量多（>100张）、数据量大的系统（电商、金融）	需跨库事务，业务逻辑复杂，跨库查询需路由
水平分表（哈希）	用户ID哈希取模，均匀分布	动态扩容易，分片数据不均衡（冷热数据）	用户表、商品表（动态数据，用户/商品增长快）	分片键固定，扩容需迁移数据，需冷热数据均衡策略
水平分表（范围）	按用户ID范围（如0-1M,1M-2M）	数据增长有规律，扩容需迁移部分数据	用户表（按注册时间）	数据分布不均，扩容复杂，需定期迁移
水平分表（时间）	按时间维度（如订单表按月）	数据按时间增长，查询按时间聚合效率高	日志表、订单表（时间序列）	分片键固定，扩容简单，但查询跨分片聚合需额外处理

4) 【示例】：假设数据库为MySQL，业务场景是高并发读低并发写（如用户信息查询频繁）。

• 垂直分库：创建用户库（user_db）、订单库（order_db）、商品库（product_db）。
• 水平分表在用户表中：分10个库（db0-db9），每个库按月分表（如202301-202312），分片键为用户ID。分片路由函数：db_index = user_id % 10，table_index = (user_id % 10) + (year-2020)*12 + month。
• 插入示例：INSERT INTO db0.user_202301 (user_id, username, phone, create_time) VALUES (123456, '张三', '13800138000', '2023-01-01');
• 查询示例：SELECT * FROM db0.user_202301 WHERE user_id = 123456;（路由到db0.user_202301表）
• 缓存预热：冷启动时，根据用户访问日志统计热门用户（如访问频率Top1000），将用户信息预加载到Redis（key为user:ID, value为用户信息），设置过期时间30分钟，并配置布隆过滤器（key为user:ID:filter）防止缓存穿透（若查询用户ID不存在，先检查布隆过滤器，若为false则直接返回404，若为true则查询数据库并缓存）。
• 分布式事务：当用户注册时，需要同时插入用户表和订单表（跨库），采用Seata AT模式，全局事务协调器管理事务，本地事务提交后，补偿事务异步复制（如每分钟一次），若检测到数据不一致则回滚并重试。

5) 【面试口播版答案】：针对百万级用户表，我会采用“垂直分库+水平分表（哈希+时间维度结合）”策略。首先，垂直分库：将用户表、订单表等按业务模块分散到不同数据库，避免单库因表多或数据量大导致性能瓶颈。水平分表：用户表按用户ID哈希取模到10个库，每个库按月分表（如202301-202312），每个库表数据量控制在10万级，平衡数据分布与查询效率。数据一致性方面，采用Seata的AT模式实现分布式事务，通过全局事务协调器管理跨库操作，补偿机制采用异步复制（每分钟校验一次）+定时回滚，确保数据最终一致性。查询性能优化：通过分片路由（根据用户ID计算库表位置）和Redis缓存预热（冷启动时预加载热门用户数据，设置30分钟过期时间，结合布隆过滤器防缓存穿透），减少全表扫描，提升首次查询速度。具体来说，查询时先检查Redis缓存，命中则直接返回，未命中则路由到对应分片读取数据并更新缓存，实现读写分离，提升性能。

6) 【追问清单】：

• 问：分片路由如何实现？答：通过分片键（用户ID）计算库和表，比如用户ID % 10得到库索引，再结合注册时间得到表索引（如(用户ID%10)+(年份-2020)*12+月份）。
• 问：如何保证数据一致性？答：用Seata AT模式，本地事务提交后，补偿事务异步复制（每分钟校验），若数据不一致则回滚并重试，避免两阶段提交的阻塞问题。
• 问：缓存预热的热门用户如何识别？答：冷启动时，根据用户访问日志统计访问频率Top1000的用户，预加载到Redis，设置30分钟过期时间，布隆过滤器过滤无效查询。
• 问：分片扩容时如何处理？答：迁移部分数据到新分片（如新增db10，将部分用户数据迁移过去），或重新哈希分片键（如用户ID哈希取模范围扩大，将数据重新分配）。
• 问：垂直分库跨库事务的复杂性如何解决？答：通过分布式事务（如Seata）拆分事务，本地事务提交后，补偿事务异步处理，确保最终一致性，避免跨库事务的阻塞问题。

7) 【常见坑/雷区】：

• 分片键选择不当：如用户ID哈希导致冷热数据不均，部分分片负载过高，影响性能。
• 分布式事务处理：两阶段提交成本高，可能导致阻塞，补偿机制更适用于高并发场景。
• 缓存雪崩：所有缓存失效，导致大量请求落库，需设置缓存过期时间（如随机过期）和热点数据预热。
• 分片迁移：迁移过程中数据不一致，需暂停业务或用补偿机制（如异步复制）保证一致性。
• 分片键动态调整：调整后数据迁移复杂，影响业务，需评估业务影响后再调整。