后台回复：1024，获取500G视频教程 推荐阅读 转行成为数据分析师 牛逼，OpenAI新模型 o1 国内直接连！ 《SQL145题第2版》正式发布！
白菜：17k～19k，（12~18薪），无签字费 SP：21k～24k，（12~18薪），签字费15w~20W（三年期） SSP：27k～29k，（12~18薪），签字费25w ~ 30W（三年期）
题目列表
2、假设你负责一个支付系统的数据库,平均每秒有1000笔交易写入,突然系统报警显示写入延迟超过500ms,你要如何处理?
3、如何设计一个千万级用户的社交网络数据库架构?
4、你如何规划和执行一个数据库从MySQL 5.7升级到MySQL 8.0的方案?
5、在一个订单系统中,发现有部分订单状态不一致：支付状态显示已支付,但账务系统显示未收到款项。请问如何定位和解决这个数据一致性问题?
6、设计一个大型电商平台的秒杀系统数据库方案,要求能支持10万人同时抢购一件商品。
7、生产环境的主从复制突然中断,从库报错 'Got fatal error 1236'。请问如何处理?
8、如何设计一个亿级用户的即时通讯系统的离线消息存储方案?
1、你在一个电商系统中发现了一个慢查询,执行时间超过3秒,请详细描述你会如何分析和优化这个问题?
使用 EXPLAIN 分析SQL执行计划 查看慢查询日志,了解SQL语句的完整执行情况 确认SQL运行的时间段(是否在业务高峰期)
如果发现没有用到索引,分析是否可以新建合适的索引 如果是因为数据量太大,考虑是否需要分表 如果是关联查询过多,考虑是否可以优化表结构
优化SQL语句本身,比如去掉不必要的JOIN 添加合适的索引 如果是统计类查询,可以考虑引入数据冗余或使用统计表 对于实时性要求不高的查询,可以加入缓存层
在测试环境验证优化效果 评估对其他业务的影响 制定回滚方案 在低峰期进行上线
2、假设你负责一个支付系统的数据库,平均每秒有1000笔交易写入,突然系统报警显示写入延迟超过500ms,你要如何处理?
检查系统资源使用情况(CPU、内存、IO) 查看数据库连接数和当前活动事务 检查是否有长事务或死锁 查看主从复制状态
如果是CPU使用率突增,可能是有全表扫描的查询 如果是IO等待高,可能是写入量突增导致 如果是内存使用高,可能是缓冲池配置问题
如果是单个查询导致,可以 kill 掉问题查询 如果是连接数过高,可以适当限制应用连接数 如果是死锁问题,可以手动解除死锁
引入读写分离 实施分库分表 优化数据库参数配置 完善监控系统
3、如何设计一个千万级用户的社交网络数据库架构?
数据特点:
用户信息变更频率低但查询频繁 关系数据量庞大且增长快 消息数据实时性要求高
具体设计方案:
-- 用户基础信息表
CREATE TABLE user_base (
user_id BIGINT PRIMARY KEY,
nickname VARCHAR(32),
avatar_url VARCHAR(256),
status TINYINT,
created_at TIMESTAMP,
-- 其他基础信息
INDEX idx_status(status)
);
-- 用户关系表(分表)
CREATE TABLE user_relation_${分片号} (
id BIGINT PRIMARY KEY,
user_id BIGINT,
follow_user_id BIGINT,
relation_type TINYINT,
created_at TIMESTAMP,
INDEX idx_user_follow(user_id, follow_user_id)
);
-- 消息表(分表)
CREATE TABLE user_message_${分片号} (
message_id BIGINT PRIMARY KEY,
sender_id BIGINT,
receiver_id BIGINT,
content TEXT,
created_at TIMESTAMP,
INDEX idx_receiver_time(receiver_id, created_at)
);
用户表考虑按照用户ID范围分片 关系表按用户ID取模分片 消息表按时间范围分表 引入Redis缓存热点数据 使用图数据库优化关系查询 考虑异地多活部署
4、你如何规划和执行一个数据库从MySQL 5.7升级到MySQL 8.0的方案?
影响评估
评估停机时间 识别不兼容特性 评估应用改造工作
升级方案制定:
准备详细的升级步骤 准备回滚方案 准备验证方案
具体执行步骤:
# 1. 在测试环境验证
mysqldump -uroot -p --all-databases > backup.sql
mysql_upgrade -uroot -p --force
# 2. 生产环境升级
# 2.1 备份数据
mysqldump -uroot -p --all-databases > prod_backup.sql
# 2.2 停机升级
systemctl stop mysql
# 安装新版本
yum install mysql-8.0
# 2.3 数据迁移
mysql_upgrade -uroot -p --force
# 2.4 验证
mysql -V
CHECK TABLE all_tables;
升级前必须做完整备份 评估需要的停机时间 准备详细的回滚方案 升级后全面的功能验证
5、在一个订单系统中,发现有部分订单状态不一致：支付状态显示已支付,但账务系统显示未收到款项。请问如何定位和解决这个数据一致性问题?
首先确认问题范围
-- 查询不一致的订单数量和分布
SELECT
DATE(create_time) as order_date,
COUNT(*) as inconsistent_count
FROM orders o
LEFT JOIN payments p ON o.order_id = p.order_id
WHERE o.status = 'PAID'
AND (p.status != 'SUCCESS' OR p.status IS NULL)
GROUP BY DATE(create_time)
ORDER BY order_date DESC;
定位可能的原因:
支付回调处理失败 事务处理异常 数据库死锁导致回滚 系统重启导致的数据丢失
数据修复方案:
-- 创建临时表记录需要修复的订单
CREATE TABLE fix_orders AS
SELECT o.order_id, o.status as order_status,
p.status as payment_status
FROM orders o
LEFT JOIN payments p ON o.order_id = p.order_id
WHERE o.status != p.status;
-- 针对每种不一致情况进行处理
UPDATE orders o
INNER JOIN payments p ON o.order_id = p.order_id
SET o.status = CASE
WHEN p.status = 'SUCCESS' THEN 'PAID'
WHEN p.status = 'FAILED' THEN 'UNPAID'
ELSE o.status
END
WHERE o.order_id IN (SELECT order_id FROM fix_orders);
长期解决方案:
实现分布式事务 增加状态校验任务 完善监控告警 引入消息队列确保可靠投递
6、设计一个大型电商平台的秒杀系统数据库方案,要求能支持10万人同时抢购一件商品。
库表设计:
-- 秒杀活动表
CREATE TABLE seckill_activity (
id BIGINT PRIMARY KEY,
product_id BIGINT NOT NULL,
title VARCHAR(64),
stock_count INT NOT NULL,
start_time TIMESTAMP,
end_time TIMESTAMP,
create_time TIMESTAMP,
status TINYINT,
INDEX idx_product(product_id),
INDEX idx_time(start_time, end_time)
) ENGINE=InnoDB;
-- 秒杀库存表(分表)
CREATE TABLE seckill_stock_${分片号} (
id BIGINT PRIMARY KEY,
activity_id BIGINT,
stock_count INT,
locked_count INT,
version BIGINT,
INDEX idx_activity(activity_id)
) ENGINE=InnoDB;
-- 秒杀订单表(分表)
CREATE TABLE seckill_order_${分片号} (
id BIGINT PRIMARY KEY,
user_id BIGINT,
activity_id BIGINT,
product_id BIGINT,
status TINYINT,
create_time TIMESTAMP,
INDEX idx_user_activity(user_id, activity_id)
) ENGINE=InnoDB;
关键技术方案:
使用Redis预热商品库存 采用乐观锁进行库存扣减 使用分布式锁防止重复下单 订单异步创建并通过消息队列投递
具体实现示例:
// 库存扣减伪代码
public boolean deductStock(Long activityId, Long userId) {
// 1. Redis预减库存
Long stock = redisTemplate.opsForValue()
.decrement("seckill:stock:" + activityId);
if (stock < 0) {
return false;
}
try {
// 2. 数据库乐观锁更新
int updated = jdbcTemplate.update(
"UPDATE seckill_stock SET " +
"stock_count = stock_count - 1, " +
"version = version + 1 " +
"WHERE activity_id = ? AND stock_count > 0 " +
"AND version = ?",
activityId, version
);
if (updated > 0) {
// 3. 异步创建订单
orderMQProducer.sendMessage(
new OrderMessage(userId, activityId));
return true;
}
} catch (Exception e) {
// 4. 回滚Redis库存
redisTemplate.opsForValue()
.increment("seckill:stock:" + activityId);
}
return false;
}
7、生产环境的主从复制突然中断,从库报错 'Got fatal error 1236'。请问如何处理?
立即检查状态:
-- 主库检查
SHOW MASTER STATUS;
SHOW BINARY LOGS;
-- 从库检查
SHOW SLAVE STATUS\G
确认问题原因:
binlog可能被主库清理 网络连接中断 磁盘空间不足 从库执行了未同步的更新
修复流程:
-- 1. 如果binlog丢失,需要重新搭建复制
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='mysql-bin.000xxx',
MASTER_LOG_POS=xxxxx;
START SLAVE;
-- 2. 检查复制状态
SHOW SLAVE STATUS\G
-- 3. 验证数据一致性
pt-table-checksum --nocheck-replication-filters \
--replicate=test.checksums \
--databases=mydb
预防措施:
合理配置binlog保留时间 监控主从延迟 定期验证数据一致性 实现自动故障转移
8、如何设计一个亿级用户的即时通讯系统的离线消息存储方案?
分库分表策略:
-- 按用户ID分库的消息表
CREATE TABLE user_message_${库号}_${表号} (
id BIGINT PRIMARY KEY,
from_uid BIGINT,
to_uid BIGINT,
msg_type TINYINT,
content TEXT,
send_time TIMESTAMP,
status TINYINT,
INDEX idx_user_time(to_uid, send_time)
) ENGINE=InnoDB;
-- 消息索引表
CREATE TABLE message_index_${分片号} (
id BIGINT PRIMARY KEY,
user_id BIGINT,
last_msg_id BIGINT,
unread_count INT,
INDEX idx_user(user_id)
) ENGINE=InnoDB;
存储方案设计:
消息ID使用雪花算法生成 消息内容考虑使用对象存储 热数据使用Redis缓存 冷数据定期归档
查询优化:
-- 优化查询示例
SELECT m.*
FROM user_message_1_1 m
INNER JOIN message_index_1 i ON m.to_uid = i.user_id
WHERE m.to_uid = ?
AND m.id < i.last_msg_id
ORDER BY m.id DESC
LIMIT 20;
关键考虑点:
消息必须有序 支持消息撤回 多终端同步 历史消息搜索
