# COUNT(*)、COUNT(1) 和 COUNT(列名) 的区别详解 - 面试必问
## 前言
前两天，一个工作四年的粉丝在面试中被问到：**COUNT(1)、COUNT(*) 和 COUNT(列名) 到底有什么区别？** 他竟然回答不上来，结果失去了一个好的 offer。
这个问题表面看很简单，但是背后考察的是你对 **SQL 语义、数据库执行逻辑，甚至线上性能的理解**。尤其是对于 3-5 年经验的开发工程师来说，这是一个很典型的基础但能区分水平的问题。
面试官希望你知道：
- COUNT(*) 是一个标准的写法，而不是网上说的 COUNT(1) 更快的一个说法
- 如果你能聊到 InnoDB 为什么 COUNT(*) 慢、MyISAM 为什么快，或者提到大表别乱用 COUNT(*) 来做分页，这些语言是在判断你：只会写 SQL，还是懂得怎么跑的
## 核心区别
### 1. COUNT(*)
**COUNT(*) 统计表里有多少行，不管列是不是 NULL，都算在里面。**
- 这是 **SQL 的标准写法**，推荐你平时就这么用
- 语义最清楚，表示统计所有行数
- 在 MySQL 中，InnoDB 引擎下需要扫描全表，性能相对较慢
- 在 MyISAM 引擎下，可以直接从元数据获取，性能很快
### 2. COUNT(1)
**COUNT(1) 跟 COUNT(*) 差不多，数据库会给每一行一个 1，然后数一遍。**
- 在 MySQL 里面，优化器会把它当成 COUNT(*) 来处理
- 所以性能上**没有什么区别**
- 从语义上来说，不如 COUNT(*) 清晰
### 3. COUNT(列名)
**COUNT(列名) 只统计这个列不为 NULL 的行。**
- 比如说你的 COUNT(UserName)，但有些用户没有填名字，那这个行就不算在里面
- **会跳过 NULL 值的判断**
- 适合用于统计特定字段的有效数据量
## 实际案例
举个例子：表里面有一百条用户记录，其中 10 个人的 NICKNAME 是 NULL。
那么：
- **COUNT(*) = 100**（统计所有行）
- **COUNT(1) = 100**（统计所有行，和 COUNT(*) 一样）
- **COUNT(NICKNAME) = 90**（只统计 NICKNAME 不为 NULL 的行）
## 面试时的标准回答
你可以这么说：
> 我一般用 **COUNT(*)**，因为它的语义是最清楚的，也是 SQL 的标准写法。
>
> **COUNT(1)** 其实和它差不多，MySQL 会优化成一样的执行计划，性能上没有什么区别。
>
> 而 **COUNT(字段)** 要小心一点，它会跳过 NULL 的判断。比如说统计"已认证用户数"的时候就很有用，但是做"总记录数"的统计就不合适了。
## 性能优化建议
1. **大表统计要谨慎**：在 InnoDB 引擎下，COUNT(*) 需要扫描全表，对于大表来说性能较差
2. **考虑使用缓存**：对于需要频繁统计总记录数的场景，可以考虑使用缓存
3. **分页查询优化**：大表分页时，不要用 COUNT(*) 来获取总数，可以考虑其他方案
## 总结
| 函数 | 统计范围 | 性能 | 使用场景 |
|------|---------|------|---------|
| COUNT(*) | 所有行（包括 NULL） | 标准写法，语义清晰 | **推荐日常使用** |
| COUNT(1) | 所有行（包括 NULL） | 与 COUNT(*) 相同 | 不推荐，语义不如 COUNT(*) 清晰 |
| COUNT(列名) | 只统计非 NULL 行 | 需要判断 NULL | 统计特定字段的有效数据量 |
## 写在最后
这个问题看似简单，但能很好地考察一个开发工程师对数据库基础知识的理解深度。掌握这些细节，不仅能帮助你在面试中脱颖而出，更能让你在实际工作中写出更高效、更准确的 SQL 语句。2、视频：【Java面试】如何在生产环境不停机的情况下实现亿级数据？_哔哩哔哩_bilibili
## 数据库不停机迁移实战指南：从面试题到实战方案
### 背景与问题
不少粉丝反馈，单纯背八股文很难在 2025 年的技术面试中脱颖而出，尤其是在二面或三面中遇到开放性场景题时常常无从下手。最近一个典型问题是：**如何在生产环境实现不停机的数据库迁移？**
这类问题表面是考迁移，但实则在考察候选人的五种能力：
- 系统架构能力
- 分布式系统理解
- 实战经验
- 风险控制
- 技术广度
很多同学没经历过类似场景，因此回答时思路不够全面。本篇文章以不停机迁移为例，帮助你建立结构化的回答框架，并对实际迁移过程进行拆解。
### 面试官关注点
1. **停机影响**：目标是在不中断业务的情况下完成迁移。
2. **数据一致性**：旧库 vs 新库的数据如何保持一致。
3. **性能影响**：迁移期间老库、新库并行，需要评估程序改造和同步方案的性能成本。
4. **异常回滚**：如果同步异常或验证不通过，如何快速回滚。
5. **验证机制**：迁移完成后如何验证数据完全一致。
理解这些关注点，才能在面试中展示自己的思考深度，而不仅仅是堆叠术语。
### 不停机迁移的核心步骤
1. **方案推演与预演**
- 在动手前完成方案设计与风险演练，明确是否涉及表结构变更、逻辑调整、数据分片等。
- 建议画出流程图或时序图，预估可能的故障点、回滚路径。
2. **全量迁移**
- 目标是把历史数据从旧库同步到新库。
- 云上可用阿里云 DTS 等工具；自建场景可用 Canal、DataX、定制脚本等。
- 数据量巨大时，需要分片并行：例如按月份或 ID 范围拆分任务，控制并发与资源占用。
3. **增量同步**
- 全量迁移期间业务仍在写入，因此要补上迁移开始后的增量数据。
- 常见方案：
- 解析 Binlog，同步增量变化，优点是对业务代码无侵入。
- 业务双写：代码层同时写旧库和新库，需要保证性能和事务一致性。
- 若使用消息队列异步写新库，需要重点处理失败重试、消息丢失、堆积等问题。
4. **异常与补偿机制**
- 双写或增量同步过程中难免出现写失败、网络抖动等情况。
- 需要记录操作日志或异常队列，提供自动/人工补偿工具，保证任何失败记录都能回放。
5. **数据校验**
- 分为全量校验和增量校验。
- 全量可用指纹校验、行数比对或分片对比；增量可将变更写入临时表/内存，对比期望值。
- 校验通过后才能进入下一步。
6. **灰度切流 & 最终切换**
- 先将读流量逐步切入新库，监控稳定后再切写流量。
- 保持旧库在线作为兜底，如果新库出问题可以立刻切回。
7. **清理与收尾**
- 切换成功后清理旧库写入通道、释放临时资源。
- 复盘迁移过程，沉淀 SOP 以备复用。
### 回答模板（面试场景）
```
面试官：如何在生产环境实现不停机数据库迁移？
候选人：
1. 先说明整体目标：不停机、数据一致、可回滚。
2. 拆步骤：
- 全量迁移：按分片并行迁移历史数据。
- 增量同步：解析 Binlog 或业务双写，确保实时数据一致。
- 校验：全量+增量校验，确认新库数据正确。
- 灰度切流：先读后写，逐步放量，保留旧库兜底。
- 回滚策略：异常时随时切回旧库。
3. 补充风险与应对：性能评估、消息堆积、异常补偿、工具选择。
```
只要逻辑清晰、结构完整，即便没有亲身经历，也能体现你的思考能力。
### 实战建议
- **提前预演**：自己写一个小型数据迁移脚本或程序，模拟双写、校验、切流等环节，可作为项目亮点。
- **工具熟悉**：了解常见的数据同步工具（DTS、Canal、DataX、DRS 等）以及 MQ、中间件的使用方式。
- **极端场景思考**：如表结构变化、跨机房迁移、大数据量下的时间评估、性能瓶颈等。
- **结构化表达**：回答时围绕“规划 → 执行 → 校验 → 切换 → 回滚”展开，每一步说明目标、方法、风险。
3、Redis 的持久化方式有哪些？RDB 和 AOF 的优缺点分别是什么？_哔哩哔哩_bilibili
# Redis 持久化原理详解 - RDB 和 AOF
## 前言
面试被问到 Redis 持久化的原理，不知道该怎么去回答？今天就来教你怎么拿捏这道经典面试题。
Redis 持久化是面试中的高频考点，掌握其原理不仅能帮助你在面试中脱颖而出，更能让你在实际工作中做出正确的技术选型。
## Redis 持久化方式
Redis 提供了 **RDB** 和 **AOF** 两种持久化方式，它们各有特点，适用于不同的业务场景。
## RDB 持久化
### 原理
**RDB（Redis Database）** 是通过生成数据库在某个时间点的快照来实现持久化的。
- 它会把内存中的数据以**二进制格式**写入磁盘
- 生成的是一个压缩的二进制文件
- 可以理解为对当前数据状态的"拍照"
### 优点
1. **文件紧凑**：RDB 文件是压缩的二进制格式，文件体积小
2. **数据恢复快**：恢复数据时直接加载二进制文件，速度很快
3. **适合备份**：可以定期生成快照，适合做数据备份
4. **对性能影响小**：fork 子进程进行持久化，主进程继续处理请求
### 缺点
1. **可能丢失数据**：如果 Redis 在两次快照之间宕机，会丢失这段时间的数据
2. **fork 子进程开销**：数据量大时，fork 子进程可能阻塞主进程
3. **不适合实时性要求高的场景**：无法做到秒级的数据持久化
### 触发方式
- 手动执行 `SAVE` 或 `BGSAVE` 命令
- 根据配置文件的规则自动触发（如 `save 900 1`）
- 执行 `SHUTDOWN` 命令时
## AOF 持久化
### 原理
**AOF（Append Only File）** 的持久化是通过记录每一条写操作的命令来实现的。
- 数据恢复时，就是把这个文件里面的所有命令重新执行一遍
- 以追加的方式记录命令，文件会不断增长
### 优点
1. **数据安全性高**：可以配置每秒同步或每次写操作同步
- 每秒同步：最多只会丢失 1 秒的数据
- 每次写操作同步：数据最安全，但性能影响较大
2. **可读性强**：AOF 文件是文本格式，可以直接查看和修改
3. **实时性好**：可以做到近实时的数据持久化
### 缺点
1. **文件体积大**：因为是命令的追加，文件会比 RDB 大很多
2. **恢复速度慢**：需要重新执行所有命令，恢复速度比 RDB 慢
3. **性能影响**：频繁的磁盘写入会影响性能（可以通过配置优化）
### 同步策略
Redis 提供了三种 AOF 同步策略：
- **always**：每次写操作都同步到磁盘（最安全，性能最低）
- **everysec**：每秒同步一次（推荐，平衡安全性和性能）
- **no**：由操作系统决定何时同步（性能最好，但可能丢失数据）
## RDB vs AOF 对比
| 特性 | RDB | AOF |
|------|-----|-----|
| **文件格式** | 二进制压缩文件 | 文本格式命令 |
| **文件大小** | 小 | 大 |
| **恢复速度** | 快 | 慢 |
| **数据安全性** | 可能丢失数据 | 数据安全性高 |
| **性能影响** | 较小 | 较大（可配置优化） |
| **适用场景** | 数据备份、灾难恢复 | 对数据安全要求高的场景 |
## 能否同时启用？
**Redis 可以同时启用 RDB 和 AOF 两种持久化方式。**
### 同时启用的优势
1. **数据更安全**：双重保障，即使一种方式出现问题，另一种方式可以恢复
2. **灵活性更高**：可以根据不同场景选择不同的恢复方式
### 恢复优先级
**当同时启用时，Redis 恢复数据会优先使用 AOF 来确保数据的完整性。**
原因：
- AOF 文件记录的是写操作命令，数据更完整
- AOF 可以保证数据的实时性更好
- 如果 AOF 文件损坏，Redis 会尝试使用 RDB 文件恢复
## 面试回答模板
### 问题：Redis 的持久化方式有哪些？
**标准回答：**
> Redis 提供了两种持久化方式：**RDB** 和 **AOF**。
>
> **RDB** 是通过生成数据库在某个时间点的快照来实现持久化的，它会把内存中的数据以二进制格式写入磁盘。优点是文件紧凑、数据恢复快，适合做数据备份；缺点是可能丢失两次快照之间的数据。
>
> **AOF** 是通过记录每一条写操作的命令来实现持久化的，数据恢复时重新执行这些命令。优点是数据安全性高，可以配置每秒同步，最多只丢失 1 秒的数据；缺点是文件比 RDB 大，恢复速度较慢，频繁的磁盘写入会影响性能。
>
> Redis 可以同时启用两种方式，恢复时会优先使用 AOF 来确保数据的完整性。
### 加分项
如果面试官继续深入，你可以提到：
1. **混合持久化**（Redis 4.0+）：结合 RDB 和 AOF 的优点
2. **AOF 重写机制**：解决 AOF 文件过大的问题
3. **实际项目经验**：根据业务场景选择合适的持久化策略
## 实际应用建议
### 选择 RDB 的场景
- 对数据丢失不敏感的业务
- 需要定期备份数据
- 数据恢复速度要求高
- 内存占用需要控制
### 选择 AOF 的场景
- 对数据安全要求高的业务
- 可以接受较慢的恢复速度
- 需要实时持久化
### 同时启用的场景
- 对数据安全要求极高
- 需要兼顾备份和实时性
- 生产环境推荐配置
## 总结
Redis 持久化是保证数据安全的重要手段，理解 RDB 和 AOF 的原理和特点，能够帮助我们在实际项目中做出正确的技术选型。
**核心要点：**
- RDB：快照方式，文件小、恢复快，但可能丢数据
- AOF：命令追加，数据安全，但文件大、恢复慢
- 可以同时启用，恢复时优先使用 AOF
- 根据业务场景选择合适的持久化策略