MySQL COUNT优化

# MySQL COUNT(*) 优化

COUNT(*) 是最常用的聚合函数，但数据量大时，COUNT(*) 可能跑得很慢。这篇说说怎么优化。

## COUNT(*) 的原理

```sql
-- MySQL 优化器会根据情况选择不同的计数方式
SELECT COUNT(*) FROM order;

-- 可能走索引扫描，也可能全表扫描
EXPLAIN SELECT COUNT(*) FROM order;
```

优化器选择策略：
1. 如果有主键或 NOT NULL 字段，扫描主键索引
2. 如果有 COUNT(*) 专用优化，用最小索引
3. 如果什么索引都没有，全表扫描

## 为什么 COUNT(*) 慢？

```sql
-- 全表扫描：InnoDB 要一行一行读出来计数
SELECT COUNT(*) FROM order; -- 1000万行，要读1000万次

-- 走索引：只读索引树，不读数据
SELECT COUNT(*) FROM order; -- 如果有主键 id，只读主键索引
```

全表扫描要读数据页，索引扫描只要读索引树。索引树比数据小很多，所以快很多。

## 优化方案

### 1. 加主键或索引

```sql
-- 最简单的优化：确保有主键
ALTER TABLE order MODIFY COLUMN id BIGINT PRIMARY KEY AUTO_INCREMENT;

-- 或者建一个专用索引
CREATE INDEX idx_id ON order(id); -- 主键本来就有索引，不用单独建

-- COUNT(*) 会自动用主键索引（最小索引）
```

### 2. 用主键 COUNT 而不是全表 COUNT

```sql
-- 优化：只 COUNT 主键列（如果有索引）
SELECT COUNT(id) FROM order; -- 走主键索引
```

### 3. 用条件 COUNT 减少扫描范围

```sql
-- ❌ 慢：COUNT 全表
SELECT COUNT(*) FROM order;

-- ✅ 快：加条件，只扫部分
SELECT COUNT(*) FROM order WHERE status = 'completed';

-- 如果 status 有索引，效果更好
CREATE INDEX idx_status ON order(status);
```

### 4. 缓存计数

对于不要求精确的数据，可以用 Redis 缓存计数。

```java
// 写入时同步更新 Redis
public void createOrder(Order order) {
orderMapper.insert(order);
redisTemplate.opsForValue().increment("order:count"); // 同步更新计数
}

// 读取时从缓存拿
public long getOrderCount() {
Long count = redisTemplate.opsForValue().get("order:count");
return count != null ? count : orderMapper.countAll();
}
```

### 5. 统计表

对于精确但不实时（允许延迟几分钟）的需求，用统计表。

```sql
-- 订单统计表
CREATE TABLE order_stats (
stat_date DATE PRIMARY KEY,
total_count BIGINT DEFAULT 0,
total_amount DECIMAL(15, 2) DEFAULT 0
);

-- 每天跑一次统计
INSERT INTO order_stats (stat_date, total_count, total_amount)
SELECT CURRENT_DATE, COUNT(*), SUM(amount) FROM order
ON DUPLICATE KEY UPDATE
total_count = VALUES(total_count),
total_amount = VALUES(total_amount);
```

### 6. INFORMATION_SCHEMA

快速查看表行数（不精确）。

```sql
-- 快速查看近似行数
SELECT TABLE_ROWS FROM information_schema.TABLES
WHERE TABLE_NAME = 'order'; -- 近似值，可能有偏差
```

## 不同 COUNT 用法对比

| 用法 | 含义 | 性能 |
|------|------|------|
| COUNT(*) | 统计所有行（包括 NULL） | 最慢 |
| COUNT(1) | 统计所有行（忽略 1） | 和 COUNT(*) 差不多 |
| COUNT(id) | 统计非 NULL 的 id | 快（走索引） |
| COUNT(col) | 统计非 NULL 的列 | 取决于有没有索引 |

```sql
-- 性能对比
SELECT COUNT(*) FROM order; -- 全表扫描
SELECT COUNT(1) FROM order; -- 全表扫描（和上面差不多）
SELECT COUNT(id) FROM order; -- 走主键索引，快
SELECT COUNT(status) FROM order; -- 走 status 索引（如果有），否则全表
```

## 实战建议

```sql
-- 查看当前 COUNT 性能
EXPLAIN SELECT COUNT(*) FROM order;

-- type = index：扫索引树，OK
-- type = ALL：全表扫描，要优化
```

### 常见场景

```sql
-- 场景1：统计总订单数（精确）
SELECT COUNT(*) FROM order; -- 定期COUNT，不要实时查

-- 场景2：统计已完成订单数（精确）
CREATE INDEX idx_status ON order(status);
SELECT COUNT(*) FROM order WHERE status = 'completed';

-- 场景3：统计用户总数（精确）
SELECT COUNT(DISTINCT user_id) FROM order;
```

## 小结

| 优化方法 | 适用场景 |
|----------|----------|
| 加主键/索引 | 所有 COUNT(*) |
| 加 WHERE 条件 | 有过滤条件的统计 |
| Redis 缓存 | 不要求精确的实时计数 |
| 统计表 | 允许几分钟延迟的统计 |
| INFORMATION_SCHEMA | 快速查看近似值 |

COUNT(*) 优化的核心就两点：**让查询走索引**，**减少扫描行数**。

---

**相关阅读：**
- [MySQL 索引底层 B+ 树原理]
- [MySQL 慢查询优化实战]
- [MySQL 执行计划 EXPLAIN 详解]