MySQL 与 Redis 高频追问
1. 为什么你的交易、支付、订阅这类状态数据放 MySQL？
推荐回答
因为这类数据最重要的是事务、一致性、状态清晰和可追溯。 像订单、支付、订阅、退款、规则配置，本质上都是强状态业务，MySQL 更适合作为主数据存储。
2. 为什么报表和分析查询不继续放 MySQL？
推荐回答
因为那是典型分析型场景，不是事务型场景。 像广告报表、ROI、优化助手这类查询，维度多、聚合重、数据量大，长期压在 MySQL 上成本高、还容易影响主库。 所以更适合拆到 ClickHouse 这类分析层。
3. MySQL 慢 SQL 你怎么排查？
推荐回答
我一般按这几个方向看：
- 有没有命中索引
- 有没有回表过多
- 是不是 where 条件设计有问题
- 是不是排序 / 分组太重
- 是不是数据量和分页方式不合理
- 是不是业务上把分析型查询压在主库了
4. 事务怎么保证一致性？
推荐回答
数据库层面看，一致性是 undo log、redo log、锁、MVCC 和约束一起保证的。 但业务上一致性不能只靠数据库，还要靠状态机、幂等、补偿和正确的事务边界。
这句很加分
数据库事务只能保证单库内一致性，复杂业务的一致性还要靠业务设计兜住。
5. Redis 在你项目里最重要的价值是什么？
推荐回答
不是简单缓存，而是：
- 缓存热点数据
- 控制幂等
- 做短期状态
- 限制重复请求
- 处理部分并发问题
很多线上问题其实不是数据库慢，而是重复请求、重复回调和热点竞争。
6. 什么时候用 Redis，什么时候不用？
推荐回答
如果是热点读、短期状态、幂等去重、排行榜、延迟任务，这些都适合 Redis。 但如果是强事务、强关系、最终真实状态，我还是更依赖 MySQL。 我不会为了快就把强状态业务过度缓存化。
7. 分布式锁你怎么理解？
推荐回答
分布式锁不是“只要加了就安全”，它本质上是协调手段。 我会先看是不是一定要加锁，很多场景其实用状态机、唯一键、条件更新就够了。 必须加锁时，才考虑 Redis 分布式锁，并且要注意超时、续期、误删和幂等问题。
8. Redis 幂等你怎么做？
推荐回答
先定义业务唯一键，再通过 Redis 记录处理标记或短期状态，保证重复请求不会重复执行关键逻辑。 但 Redis 只是工具，最终还是要结合数据库状态判断，避免 Redis 状态和业务真实状态脱节。
9. 订单超时关闭为什么可以用 Redis ZSet？
推荐回答
因为 ZSet 天然有 score 排序能力，可以把超时时间作为 score。 到时间后按 score 扫描一批到期订单，再做状态判断和关闭。 它的价值在于避免全表扫数据库，但真正关闭订单还是要走数据库条件更新和幂等控制。
10. MySQL 和 Redis 怎么配合更合理？
推荐回答
MySQL 负责真实业务状态，Redis 负责性能和并发控制。 主状态永远以 MySQL 为准，Redis 更多是缓存层、幂等层、热点层，不应该反过来。