---
tags: [MySQL, 踩坑, FileSort, 隐式转换, TIMESTAMP, DATETIME, AUTO_INCREMENT, FULLTEXT, 幻读, LEFT JOIN]
create time: 2026-05-16 00:30
---

# 常见踩坑

## 概述

MySQL 的设计有许多「反直觉」的行为。本章汇总最常见的陷阱和误区，帮助你在编码阶段就规避这些问题。

## 1. ORDER BY 产生 FileSort

```sql
-- ❌ 看似有索引，但实际上触发了 FileSort
CREATE INDEX idx_status ON orders(status);

EXPLAIN SELECT * FROM orders
WHERE status = 'pending'
ORDER BY created_at DESC;
-- Extra: Using where; Using filesort

-- 为什么？idx_status 只按 status 排序，created_at 是无序的
-- 虽然 WHERE 能用索引过滤，但 ORDER BY 无法利用该索引

-- ✅ 解决方法：创建联合索引
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);

-- 现在的 EXPLAIN:
-- key: idx_status_created
-- Extra: Using where  ← No filesort! 因为索引里已经是有序的
```

```mermaid
flowchart LR
    IDX["联合索引 idx(status, created_at)"]
    
    IDX -->|"WHERE status=? ORDER BY created_at"| PERF["✅ 完全利用索引顺序"]
    IDX -->|"WHERE status=? LIMIT 100"| PERF
    
    single_idx["单列索引 idx(status)"]
    single_idx -->|"WHERE status=? ORDER BY created_at"| SORT["❌ Filesort<br/>内存排序"]
    
    style PERF fill:#00D866,color:#fff
    style SORT fill:#EE5A24,color:#fff
```

> [!TIP] 教学要点
> **问题**：为什么已有索引还不够？
> **回答**：B+树索引只能保证第一列有序。当 WHERE 固定了第一列的值后，剩余行的第二列仍然保持插入顺序，而非目标字段的排序顺序。

## 2. COUNT(*) vs COUNT(1) vs COUNT(column)

```sql
-- 三者语义不同，但在 InnoDB 中 COUNT(*) 最快
SELECT COUNT(*) FROM users;       -- 统计行数（忽略 NULL）
SELECT COUNT(1) FROM users;       -- 同 COUNT(*)（InnoDB 优化相同）
SELECT COUNT(email) FROM users;   -- 统计 email 非 NULL 的行数
SELECT COUNT(DISTINCT city) FROM users;  -- 去重计数

-- InnoDB 优化细节
-- COUNT(*) 直接扫描聚簇索引的最左叶子页开始计数（O(N)）
-- COUNT(column) 除了扫描还需要检查是否为 NULL → 稍慢
-- COUNT(DISTINCT) 需要额外排序/去重 → 最慢
```

```mermaid
graph TB
    subgraph "性能对比 (由快到慢)"
        A["COUNT(*)<br/>只数行数"] -->|快 10\%~30\%| B["COUNT(1)<br/>优化器等价"]
        B -->|稍慢| C["COUNT(col)<br/>需判 NULL"]
        C -->|最慢| D["COUNT(DISTINCT col)<br/>需排序去重"]
    end
    
    style A fill:#00D866,color:#fff
    style B fill:#7BED9F,color:#000
    style C fill:#FFA500,color:#fff
    style D fill:#EE5A24,color:#fff
```

> [!TIP] 结论
> - 如果你只是想统计行数 → 用 `COUNT(*)`
> - `COUNT(1)` 和 `COUNT(*)` 在 InnoDB 中是完全等价的（优化器视为同一计划）
> - 不要在 COUNT 中放列名除非你真的要排除 NULL 值
> 
> **问题思考**：为什么 `COUNT(*)` 不需要逐行判断字段值？因为 InnoDB 内部维护了行计数器，直接从聚簇索引叶子节点遍历即可。

## 3. TIMESTAMP 自动更新陷阱

```sql
CREATE TABLE events (
    id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP 
        ON UPDATE CURRENT_TIMESTAMP  -- ← 这里！
);

INSERT INTO events (name) VALUES ('Meeting');
-- created_at = 2026-05-16 10:00:00
-- updated_at = 2026-05-16 10:00:00

-- 即使只修改 name，updated_at 也会自动更新
UPDATE events SET name = 'New Meeting' WHERE id = 1;
-- updated_at = 2026-05-16 10:05:00 ← 自动更新了！

-- 但如果修改的是 created_at 呢？
UPDATE events SET created_at = '2026-01-01 00:00:00' WHERE id = 1;
-- updated_at 同样会自动更新为当前时间！
-- 这就是陷阱——修改任何字段都会触发 ON UPDATE
```

> [!WARNING] 独立创建时间和更新时间
> ```sql
> -- 推荐模式：created_at 不使用 ON UPDATE，updated_at 用 ON UPDATE
> CREATE TABLE good_events (
>     id BIGINT PRIMARY KEY,
>     name VARCHAR(100),
>     created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,  -- 不受 ON UPDATE 影响
>     updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
> );
> ```

> [!TIP] 为什么修改 created_at 也会触发 ON UPDATE？
> `ON UPDATE CURRENT_TIMESTAMP` 作用于**整行**而非特定列。任何字段的更新都会让 `updated_at` 刷新为当前时间。这不是 bug，是 MySQL 的设计语义——"此行被修改了"。

## 4. VARCHAR 长度计算

```sql
-- utf8mb4 下，VARCHAR(n) 的最大字节数 = n × 4
-- MySQL 一行最大 65535 字节

-- ❌ 看起来合理，实际超限
CREATE TABLE bad_table (
    col1 VARCHAR(16383),  -- 16383 × 4 = 65532 bytes + 2 bytes length prefix = 65534 ✓
    col2 CHAR(1)          -- 1 × 4 = 4 bytes + overhead = ❌ 超出 65535 行限制
);
-- ERROR 1118: Row size too large

-- ✅ 解决方案
CREATE TABLE good_table (
    col1 VARCHAR(16382),  -- 留余量
    col2 LONGTEXT         -- 大文本走外存
);
```

> [!WARNING] 关于 65535 的常见误区
> - 65535 是**行级别**的硬限制（不含 TEXT/BLOB 等外部存储字段）
> - `VARCHAR(n)` 需要 **1~2 字节**的长度前缀来记录实际数据长度
> - `innodb_large_prefix=ON` 时可突破到约 8KB（配合 DYNAMIC 页格式），但跨引擎兼容性差，不建议依赖
> 
> **问题思考**：为什么 TEXT/BLOB 不计入行大小限制？因为它们的数据存储在溢出页（overflow pages）中，行内只保留一个 20 字节的指针。

## 5. LEFT JOIN 条件位置

```sql
-- ❌ 把 LEFT JOIN 的过滤条件放在 WHERE，等效于 INNER JOIN
SELECT u.name, o.amount
FROM users u LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'paid';  
-- WHERE o.status 会把 LEFT JOIN 的结果过滤掉不匹配的行 → 变成 INNER JOIN

-- ✅ 正确：把条件放在 ON 子句
SELECT u.name, COALESCE(SUM(CASE WHEN o.status = 'paid' THEN o.amount ELSE 0 END), 0)
FROM users u 
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';

-- ✅ 或者：过滤右表应该在 WHERE 中显式检查 NULL
SELECT u.name, o.amount
FROM users u LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'paid' OR o.id IS NULL;
```

> [!TIP] LEFT JOIN vs INNER JOIN 的快速判断
> **口诀**：左表的过滤条件放 WHERE（不影响左表完整性），右表的过滤条件放 ON（保留左表全量）。
> 
> **问题思考**：如果 WHERE 中的列来自两张表（`WHERE u.city = 'Beijing' AND o.status = 'paid'`）会怎样？
> **回答**：此时 WHERE 先执行 JOIN，再对结果集做二次过滤。这仍然是 LEFT JOIN，只是部分数据被 WHERE 筛掉了——它不会退化为 INNER JOIN。

## 6. 隐式类型转换导致索引失效

```sql
-- phone 是 VARCHAR(20)
ALTER TABLE users ADD INDEX idx_phone (phone);

-- ❌ 传入了 INT，MySQL 自动把 phone 转成 INT 再比较
SELECT * FROM users WHERE phone = 13800138000;
-- EXPLAIN: type=ALL, Rows=1000000 → 索引失效

-- ✅ 始终传入字符串
SELECT * FROM users WHERE phone = '13800138000';
-- EXPLAIN: type=ref, key=idx_phone → 走索引

-- 类似陷阱
SELECT * FROM users WHERE id = '12345';  
-- varchar 列传 int 同理，MySQL 会做隐式转换
```

> [!WARNING] 隐式转换的核心规则
> - MySQL 的转换优先级：**INT > VARCHAR**。当列类型为 VARCHAR、值为 INT 时，MySQL 会把**每一行的 VARCHAR 值转为 INT**再比较 → 索引失效。
> - 反之（列是 INT、传入 VARCHAR），MySQL 会将传入值转为 INT → **索引依然生效**。
> - **结论**：永远让参数类型与列类型严格一致。这是后端 ORM 框架最容易忽略的点。

## 7. datetime 的精度与范围

```sql
-- MySQL 8.0 默认 datetime(0) — 不带小数秒
CREATE TABLE t1 (dt DATETIME);
INSERT INTO t1 VALUES ('2026-05-16 10:30:45.123456');
SELECT dt FROM t1;
-- 输出: 2026-05-16 10:30:45  ← 微秒丢失！

-- ✅ 如果需要保留精度
CREATE TABLE t2 (dt DATETIME(6));
INSERT INTO t2 VALUES ('2026-05-16 10:30:45.123456');
SELECT dt FROM t2;
-- 输出: 2026-05-16 10:30:45.123456
```

```mermaid
graph LR
    subgraph "DATETIME vs TIMESTAMP"
        A["DATETIME<br/>存储: 8 bytes<br/>范围: 1000~9999<br/>不受时区影响"] --> B["适合业务时间<br/>如订单创建时间"]
        C["TIMESTAMP<br/>存储: 4 bytes<br/>范围: 1970~2038<br/>受 server 时区影响"] --> D["适合审计字段<br/>如最后登录时间"]
    end
    
    style B fill:#00D866,color:#fff
    style D fill:#FFA500,color:#fff
```

> [!WARNING] TIMESTAMP 有上限问题
> TIMESTAMP 的最大值是 `2038-01-19 03:14:07`。如果你的系统需要在 2038 年之后使用，务必改用 `DATETIME`，否则会遇到无法插入数据的诡异 bug。这也是为什么很多团队统一只用 DATETIME。

## 8. AUTO_INCREMENT 删除后的断号问题

```sql
CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50)
);

INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie'), ('Dave');
DELETE FROM users WHERE id IN (2, 3);
-- 当前 id: 1, 4
INSERT INTO users (name) VALUES ('Eve');
-- Eve 的 id = 5（不会复用 2 或 3）
```

> [!WARNING] 自动递增号的特性
> - AUTO_INCREMENT **不会回收已删除的值**。这是设计使然——保证全局唯一且有序追加写友好。
> - 如果业务需要**紧凑编号**（如内部工号），必须手动处理（如重建表或使用序列表），但**不建议在生产系统这样做**。
> - InnoDB 的 AUTO_INCREMENT 锁在内存中（mysql.auto_increment_helper 表），即使删除所有行也不会归零（除非 TRUNCATE）。

## 9. LIKE 前缀通配符导致全表扫描

```sql
ALTER TABLE products ADD INDEX idx_name (name);

-- ❌ 前缀通配符 → 索引失效
SELECT * FROM products WHERE name LIKE '%手机%';
-- EXPLAIN: type=ALL → 全表扫描！

-- ✅ 前缀固定 → 可以利用索引（最左前缀匹配）
SELECT * FROM products WHERE name LIKE '手机%';
-- EXPLAIN: type=range → 走索引范围扫描

-- ✅ 替代方案：使用全文索引
ALTER TABLE products ADD FULLTEXT INDEX ft_name (name);
SELECT * FROM products WHERE MATCH(name) AGAINST('手机');
```

> [!TIP] LIKE 索引利用规则速查
> | 模式 | 是否走索引 | 原因 |
> |------|-----------|------|
> | `'abc%'` | ✅ | 可定位起始位置 |
> | `'%abc'` | ❌ | 未知起始位置 |
> | `'%abc%'` | ❌ | 同上 |
> 
> **建议**：对中文搜索需求优先使用 Elasticsearch 等专业搜索引擎，不要依赖 LIKE。

## 10. 可重复读（RR）下的幻读陷阱

```sql
-- Session A                  -- Session B
BEGIN;                        BEGIN;
                              INSERT INTO orders ...;   ← 成功！
COMMIT;                      COMMIT;
SELECT COUNT(*) FROM orders;  -- 结果包含了 B 插入的行
```

```mermaid
sequenceDiagram
    participant A as Session A
    participant DB as InnoDB
    participant B as Session B
    
    A->>A: BEGIN
    A->>DB: SELECT COUNT(*)
    Note over A,DB: 读到 10 行
    
    B->>B: BEGIN
    B->>DB: INSERT row_11
    B->>DB: COMMIT
    
    A->>DB: SELECT COUNT(*)
    Note over A,DB: RR 级别下仍读到 11 行<br/>（Read View 未刷新）
    
    A->>DB: UPDATE ... WHERE id > 100
    Note over A,DB: 间隙锁发现新行<br/>→ 阻塞等待 B 的事务释放
```

> [!WARNING] RR 隔离级别的幻读是「有条件」的
> - **普通 SELECT** 不会看到其他事务的新数据吗？**不一定**。InnoDB 的快照读只读第一次创建 Read View 时的状态，但 DML（UPDATE/DELETE）会刷新视图并感知新行。
> - `SELECT ... FOR SHARE / FOR UPDATE` 会使用 next-key lock 阻止幻读——这才是真正的「不可幻读」。
> - MySQL 的 RR ≠ SQL 标准定义的「完全隔离幻读」。这是最容易产生误解的地方之一。

## 11. 关联笔记

- [[hhs/MySQL/03-索引与查询优化/15-EXPLAIN 完全指南]] — 通过 EXPLAIN 识别上述问题
- [[hhs/MySQL/03-索引与查询优化/14-联合索引与最左前缀]] — 索引失效的典型原因
- [[hhs/MySQL/03-索引与查询优化/17-查询改写技巧]] — 各种问题的改写方案