数据库理论与优化面试题

SunnyFan大约 17 分钟约 5220 字

数据库理论与优化面试题

简介

数据库理论与优化是后端开发和 DBA 面试中最核心的考察方向之一。无论是关系型数据库（SQL Server、MySQL、PostgreSQL）还是 NoSQL 数据库（MongoDB、Redis），理解索引原理、事务机制、查询优化和锁策略都是写出高效数据访问代码的前提。本文整理了数据库面试中的高频问题，涵盖索引原理、事务隔离、SQL 优化、锁机制和数据库设计等方面，帮助候选人系统性地准备数据库相关面试。

特点

覆盖数据库核心理论知识体系
面试高频考点全面梳理，附详细答案解析
结合 SQL Server / MySQL / PostgreSQL 多数据库视角
包含实际 SQL 优化案例和排错思路

索引原理

1. 什么是索引？数据库索引的底层实现是什么？

索引是数据库中用于加速数据检索的数据结构。它类似于书籍的目录，通过预先排序和建立指针，避免全表扫描，快速定位到目标数据。

B+ Tree（MySQL InnoDB 默认索引结构）：

B+ Tree 结构示意：

        [30 | 60]              ← 根节点（非叶子节点）
       /    |    \
   [10|20] [40|50] [70|80]     ← 中间节点
    |   |   |   |   |   |
   [1] [2] [3] [4] [5] [6]     ← 叶子节点（包含实际数据指针）
    └──────────────────────────┘
         双向链表连接（范围查询优化）

特点：
1. 非叶子节点只存储索引键值，不存储实际数据
2. 所有数据都在叶子节点，叶子节点通过双向链表连接
3. 每个节点可以存储多个键值（多路搜索树）
4. 树的高度通常 3-4 层，一次查询只需 3-4 次 IO
5. 叶子节点链表支持高效的范围查询（BETWEEN、>、<）

B Tree vs B+ Tree 对比：

对比项	B Tree	B+ Tree
数据存储	所有节点都存数据	只有叶子节点存数据
范围查询	需要中序遍历	叶子节点链表直接遍历
单次查询 IO	不确定（数据可能在非叶子节点）	确定（必须到叶子节点）
扇出（Fan-out）	较低（节点存储数据占空间）	较高（非叶子节点只存键值）

2. 聚集索引和非聚集索引的区别？

对比项	聚集索引（Clustered Index）	非聚集索引（Non-Clustered Index）
数据存储	叶子节点存储完整数据行	叶子节点存储索引键 + 聚集索引键（回表指针）
数量限制	每表只能有一个	每表可以有多个
查询效率	覆盖查询时最快，无需回表	需要回表查聚集索引获取完整数据
适合列	主键、经常范围查询的列	经常 WHERE/JOIN 的列
排序	物理排序数据	逻辑排序索引键

回表（Bookmark Lookup）：

非聚集索引查询流程：
1. 在非聚集索引 B+ Tree 中查找索引键
2. 找到叶子节点中的聚集索引键值
3. 用聚集索引键在聚集索引 B+ Tree 中查找完整数据行
4. 如果步骤 3 需要 IO，这就是"回表"

减少回表的方法：
1. 覆盖索引：将查询需要的所有列都包含在非聚集索引中
2. 索引下推（ICP）：在存储引擎层先过滤再回表
3. 只查询索引列：SELECT 列表只包含索引中的列

-- 覆盖索引示例
-- 索引：CREATE INDEX idx_name_email ON users(name, email)

-- 覆盖查询（不需要回表）
SELECT name, email FROM users WHERE name = '张三';
-- name 和 email 都在索引中，直接从索引返回

-- 非覆盖查询（需要回表）
SELECT name, email, phone, address FROM users WHERE name = '张三';
-- phone 和 address 不在索引中，需要回表查聚集索引

-- 使用 INCLUDE 创建覆盖索引（SQL Server 语法）
CREATE INDEX idx_name_email_cover
ON users(name, email)
INCLUDE (phone, address);
-- 包含列不参与索引排序，但存储在叶子节点中

3. 什么是索引下推（Index Condition Pushdown）？

索引下推是 MySQL 5.6 引入的优化，将 WHERE 条件中可以用索引过滤的部分"下推"到存储引擎层执行，减少回表次数。

-- 示例：联合索引 (name, age)
SELECT * FROM users WHERE name LIKE '张%' AND age = 25;

-- 没有 ICP（MySQL 5.6 之前）：
-- 1. 存储引擎通过索引找到 name LIKE '张%' 的所有行
-- 2. 返回给 Server 层
-- 3. Server 层过滤 age = 25
-- 问题：步骤 1 可能返回很多行，回表次数多

-- 有 ICP（MySQL 5.6+）：
-- 1. 存储引擎通过索引找到 name LIKE '张%' 的行
-- 2. 在存储引擎层直接过滤 age = 25
-- 3. 只将满足条件的行返回给 Server 层
-- 优化：减少了回表次数

-- 查看 ICP 是否生效
EXPLAIN SELECT * FROM users WHERE name LIKE '张%' AND age = 25;
-- Extra 列显示：Using index condition

事务与锁

4. 数据库事务的 ACID 特性是什么？

特性	含义	实现机制
原子性（Atomicity）	事务中的操作要么全部成功，要么全部回滚	Undo Log（回滚日志）
一致性（Consistency）	事务前后数据满足所有约束条件	约束检查 + 其他三个特性
隔离性（Isolation）	并发事务之间互不影响	MVCC + 锁机制
持久性（Durability）	提交的事务永久保存，不丢失	Redo Log（重做日志）

-- ACID 的实际体现

-- 原子性：转账要么成功要么失败
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- 两条 UPDATE 同时生效或同时回滚

-- 一致性：约束检查
CREATE TABLE accounts (
    id INT PRIMARY KEY,
    balance DECIMAL(10,2) CHECK (balance >= 0)
);
-- 转账后余额不能为负数

-- 隔离性：并发控制
-- 事务 A 读取余额时，事务 B 的修改对 A 不可见（取决于隔离级别）

-- 持久性：COMMIT 后数据写入磁盘
-- 即使系统崩溃，通过 Redo Log 恢复已提交的事务

5. 事务隔离级别有哪些？各解决什么并发问题？

隔离级别	脏读	不可重复读	幻读	性能
Read Uncommitted	可能	可能	可能	最高
Read Committed	不可能	可能	可能	高
Repeatable Read	不可能	不可能	可能（InnoDB 已解决）	中
Serializable	不可能	不可能	不可能	最低

三种并发问题详解：

-- 脏读（Dirty Read）：读到其他事务未提交的数据
-- 事务 A                           事务 B
BEGIN;                            BEGIN;
UPDATE accounts SET balance = 0
WHERE id = 1;
                                  SELECT balance FROM accounts WHERE id = 1;
                                  -- 读到 balance = 0（脏数据）
ROLLBACK;                        -- 事务 A 回滚，balance 恢复原值
                                  -- 事务 B 读到了不存在的数据

-- 不可重复读（Non-Repeatable Read）：同一事务中两次读取结果不同
-- 事务 A                           事务 B
BEGIN;
SELECT balance FROM accounts
WHERE id = 1;
-- 读到 balance = 1000
                                  UPDATE accounts SET balance = 500
                                  WHERE id = 1;
                                  COMMIT;
SELECT balance FROM accounts
WHERE id = 1;
-- 读到 balance = 500（两次读取不一致）
COMMIT;

-- 幻读（Phantom Read）：同一事务中两次范围查询结果行数不同
-- 事务 A                           事务 B
BEGIN;
SELECT * FROM accounts
WHERE balance > 500;
-- 返回 5 行
                                  INSERT INTO accounts VALUES (3, 1000);
                                  COMMIT;
SELECT * FROM accounts
WHERE balance > 500;
-- 返回 6 行（多了一行"幻影"）
COMMIT;

6. MVCC（多版本并发控制）的原理是什么？

MVCC 是一种无锁读机制，通过为每行数据维护多个版本，实现读不阻塞写、写不阻塞读。

InnoDB MVCC 实现：

每行数据隐藏的额外字段：
┌──────────┬──────────┬──────────────────┐
│ DB_TRX_ID │ DB_ROLL_PTR│ DB_ROW_ID      │
│ 最后修改   │ 指向 Undo │ 隐藏主键       │
│ 事务 ID   │ Log 指针   │               │
├──────────┴──────────┴──────────────────┤
│ name      │ balance  │ ...             │  ← 实际数据列
└──────────┴──────────┴──────────────────┘

Undo Log 链（版本链）：
当前行 (trx_id=300, balance=500)
    ↑ DB_ROLL_PTR
旧版本 (trx_id=200, balance=1000)
    ↑ DB_ROLL_PTR
更旧版本 (trx_id=100, balance=2000)

Read View（读视图）：
事务开始时创建，记录当前活跃事务列表
┌───────────────────────────────────┐
│ m_ids: [200, 300]  活跃事务 ID    │
│ min_trx_id: 200    最小活跃事务    │
│ max_trx_id: 301    下一个分配的事务 │
│ creator_trx_id: 250 创建此视图的事务│
└───────────────────────────────────┘

可见性判断规则：
1. trx_id < min_trx_id → 可见（在视图创建前已提交）
2. trx_id >= max_trx_id → 不可见（在视图创建后开始）
3. trx_id in m_ids → 不可见（活跃事务，未提交）
4. trx_id == creator_trx_id → 可见（自己的修改）
5. 其他 → 通过 Undo Log 找上一个版本，重复判断

SQL 优化

7. SQL 查询优化有哪些常见手段？

-- 1. 避免 SELECT *
-- 差：返回所有列，增加 IO 和网络传输
SELECT * FROM orders WHERE customer_id = 1001;

-- 好：只查需要的列
SELECT order_id, amount, created_at
FROM orders WHERE customer_id = 1001;

-- 2. 避免在 WHERE 子句中对列使用函数
-- 差：索引失效（对列使用函数后索引无法匹配）
SELECT * FROM orders WHERE DATE(created_at) = '2024-01-15';

-- 好：索引有效
SELECT * FROM orders
WHERE created_at >= '2024-01-15 00:00:00'
  AND created_at < '2024-01-16 00:00:00';

-- 3. 避免隐式类型转换
-- 差：phone 是 VARCHAR 类型，传入数字导致隐式转换
SELECT * FROM users WHERE phone = 13800138000;

-- 好：类型匹配
SELECT * FROM users WHERE phone = '13800138000';

-- 4. 使用 EXISTS 代替 IN（子查询结果集大时）
-- 差：IN 先执行子查询，可能产生大量临时数据
SELECT * FROM orders
WHERE customer_id IN (SELECT id FROM customers WHERE city = '北京');

-- 好：EXISTS 利用索引，找到匹配就停止
SELECT * FROM orders o
WHERE EXISTS (SELECT 1 FROM customers c
              WHERE c.id = o.customer_id AND c.city = '北京');

-- 5. 合理使用 JOIN
-- 确保 JOIN 列有索引
CREATE INDEX idx_orders_customer_id ON orders(customer_id);
SELECT o.order_id, o.amount, c.name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
WHERE c.city = '北京';

-- 6. 分页优化（大偏移量）
-- 差：OFFSET 1000000 需要先扫描前 1000000 行
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 1000000;

-- 好：使用游标分页（记住上一页最后一条的 ID）
SELECT * FROM orders
WHERE created_at < '2024-01-01 00:00:00'
ORDER BY created_at DESC
LIMIT 20;

-- 7. 使用 EXPLAIN 分析执行计划
EXPLAIN ANALYZE
SELECT o.order_id, c.name, o.amount
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.city = '北京'
ORDER BY o.amount DESC
LIMIT 100;

8. EXPLAIN 执行计划如何解读？

-- MySQL EXPLAIN 关键字段
EXPLAIN SELECT * FROM users WHERE name = '张三';

-- id：查询标识符（子查询会有多个 id）
-- select_type：查询类型（SIMPLE, PRIMARY, SUBQUERY, DERIVED）
-- table：访问的表
-- type：访问类型（从优到差）：
--   system > const > eq_ref > ref > range > index > ALL
--   ALL = 全表扫描（最差）
--   index = 索引全扫描
--   range = 索引范围扫描
--   ref = 索引等值查找
--   eq_ref = 唯一索引等值查找
-- possible_keys：可能使用的索引
-- key：实际使用的索引（NULL 表示没使用索引）
-- key_len：使用索引的字节数
-- rows：预估扫描行数
-- filtered：过滤比例
-- Extra：额外信息
--   Using index = 覆盖索引
--   Using where = 在存储引擎检索后进行过滤
--   Using temporary = 使用临时表
--   Using filesort = 文件排序（需要优化）
--   Using index condition = 索引下推

数据库设计

9. 范式与反范式的区别？实际项目中如何选择？

数据库范式：

第一范式（1NF）：列不可再分
第二范式（2NF）：非主键列完全依赖于主键（消除部分依赖）
第三范式（3NF）：非主键列直接依赖于主键（消除传递依赖）

反范式：适度违反范式，通过冗余数据减少 JOIN 操作，提升查询性能。

-- 范式化设计（3NF）
-- 订单表：order_id, customer_id, amount
-- 客户表：customer_id, customer_name, city
-- 查询时需要 JOIN
SELECT o.order_id, c.customer_name, o.amount
FROM orders o
JOIN customers c ON o.customer_id = c.id;

-- 反范式设计（冗余客户名称）
-- 订单表：order_id, customer_id, customer_name, amount
-- 查询时不需要 JOIN
SELECT order_id, customer_name, amount
FROM orders;

-- 实际项目中的选择原则：
-- 1. OLTP 系统（高并发写入）：偏向范式化，减少数据冗余和更新异常
-- 2. OLAP 系统（高并发读取）：偏向反范式化，减少 JOIN，提升查询速度
-- 3. 报表/统计表：使用反范式或预聚合
-- 4. 配置/字典表：适当反范式，减少关联查询

10. 什么是分库分表？有哪些方案？

分库分表是应对单表数据量过大（通常超过 500 万-1000 万行）的性能优化手段。

垂直拆分：按业务功能拆分

原始表：user(id, name, avatar, bio, address, settings, ...)
拆分后：
user_base(id, name, avatar)      -- 基础信息
user_profile(id, bio, settings)  -- 详细信息
user_address(id, province, city, detail)  -- 地址信息

水平拆分：按规则分散到多个表/库

原始表：orders(id, user_id, amount, ...)
拆分后（按 user_id 取模）：
orders_0 (user_id % 4 == 0)
orders_1 (user_id % 4 == 1)
orders_2 (user_id % 4 == 2)
orders_3 (user_id % 4 == 3)

分片策略：
1. 哈希取模：user_id % N（均匀分布，但扩容困难）
2. 范围分片：按时间或 ID 范围（容易数据倾斜）
3. 一致性哈希：减少扩容时的数据迁移

常见中间件：ShardingSphere、MyCat（Java）；EF Core 拦截器（.NET）

优点

面试考点覆盖全面，从索引原理到分库分表
每道题目提供详细解析和 SQL 示例
多数据库视角（MySQL、SQL Server、PostgreSQL）
结合实际项目场景给出选型建议

缺点

题目数量有限，无法覆盖所有数据库知识点
部分答案需要结合实际项目经验才能深入理解
缺少 NoSQL 数据库的深入优化内容
分布式事务和一致性问题是另一个大话题

总结

数据库理论与优化面试题涵盖了索引原理、事务隔离、SQL 优化、锁机制和数据库设计等核心领域。掌握这些知识点不仅有助于通过面试，更是编写高效数据访问代码的基础。建议在学习过程中多使用 EXPLAIN 分析实际 SQL，结合执行计划理解索引和优化的效果。

这组题真正考什么

面试官往往不只是考定义，而是在看你能否把数据库知识放回真实项目
这类题经常沿着"为什么慢、怎么优化、优化后有什么代价"往下追问
高分答案通常有三层：结论、原理、项目中的实际案例

60 秒答题模板

先用一句话给结论
再补关键原理或底层机制
最后说适用边界、常见坑或项目中的使用经验

容易失分的点

只会背术语，不会举实际 SQL 示例
回答太散，没有结构
忽略不同数据库之间的差异
只说优点不说代价（如索引增加写入开销）

刷题建议

把答案拆成"定义、原理、SQL 示例、项目场景"四段来复述
每道索引题都自己写一个 EXPLAIN 验证
高频概念题建议自己再追问一层：底层实现、性能代价、常见问题分别是什么

高频追问

如果面试官继续追问底层实现，你能否解释 B+ Tree 的分裂和合并过程？
如果放到分库分表场景下，分布式事务怎么处理？
是否存在版本差异（如 MySQL 5.7 vs 8.0 的索引优化差异）？

复习重点

索引原理（B+ Tree、聚集/非聚集、覆盖索引、索引下推）
事务隔离（四种级别、MVCC 原理）
SQL 优化（EXPLAIN 解读、常见反模式）
锁机制（共享锁、排他锁、死锁检测）

面试作答提醒

先给结论，再补原理和 SQL 示例
回答优化题时，先说问题再给方案和效果
如果记不清细节，优先说出分析思路（如 EXPLAIN）

锁机制

11. 数据库锁有哪些类型？如何避免死锁？

-- 共享锁（S 锁 / 读锁）
-- 多个事务可以同时持有共享锁，但阻止排他锁
SELECT * FROM orders WITH (TABLOCKX) WHERE id = 1;  -- SQL Server 表级锁
SELECT * FROM orders LOCK IN SHARE MODE WHERE id = 1;  -- MySQL 共享锁

-- 排他锁（X 锁 / 写锁）
-- 只有一个事务可以持有，阻止所有其他锁
SELECT * FROM orders FOR UPDATE WHERE id = 1;  -- MySQL 排他锁
UPDATE orders SET amount = 500 WHERE id = 1;   -- 自动加排他锁

-- 意向锁（IS/IX）
-- InnoDB 自动添加，表示事务打算在更细粒度上加锁
-- 例如：事务要对某行加 X 锁，会先对表加 IX 锁

-- 行锁 vs 表锁 vs 间隙锁
-- 行锁：锁定索引记录（InnoDB 默认）
-- 表锁：锁定整张表（MyISAM 默认）
-- 间隙锁（Gap Lock）：锁定索引记录之间的间隙，防止幻读

InnoDB 锁的兼容矩阵：

      IS    IX    S     X
IS   兼容  兼容  兼容  冲突
IX   兼容  兼容  冲突  冲突
S    兼容  冲突  兼容  冲突
X    冲突  冲突  冲突  冲突

避免死锁的原则：
1. 按固定顺序访问表和行（例如按 id 升序）
2. 保持事务简短，减少持锁时间
3. 使用低隔离级别（如 Read Committed）
4. 合理使用索引，避免行锁升级为表锁
5. 设置锁等待超时：innodb_lock_wait_timeout = 10（秒）

12. 什么是乐观锁和悲观锁？

-- 悲观锁：假设一定会冲突，先加锁再操作
BEGIN;
SELECT * FROM products WHERE id = 1 FOR UPDATE;  -- 加排他锁
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT;

-- 乐观锁：假设不会冲突，提交时检查版本号
-- 表需要加 version 字段
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    stock INT,
    version INT DEFAULT 0
);

-- 更新时检查版本号
UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 1 AND version = 5;

-- 如果 affected rows = 0，说明版本号已变（被其他事务修改），需要重试

-- 乐观锁的代码实现模式（C# 示例伪代码）
-- int affected = db.Execute(
--     "UPDATE products SET stock = @stock, version = version + 1
--      WHERE id = @id AND version = @version",
--     new { stock = newStock, id = productId, version = currentVersion });
-- if (affected == 0) throw new ConcurrencyException("数据已被修改");

连接池与性能调优

13. 数据库连接池的原理和配置？

-- 连接池的核心参数（以 SQL Server 为例）
-- 连接字符串中的池化配置：
-- Server=...;Database=...;Pooling=true;
-- Max Pool Size=100;     -- 最大连接数
-- Min Pool Size=5;       -- 最小连接数
-- Connect Timeout=30;    -- 连接超时（秒）
-- Connection Lifetime=0; -- 连接最长存活时间（0=不限制）

-- MySQL 连接池配置（Connector/NET）：
-- Server=...;Database=...;
-- Max Pool Size=100;
-- Min Pool Size=5;
-- Connection Timeout=30;
-- Connection Idle Timeout=180;

-- 连接池工作原理：
-- 1. 应用请求连接时，池中有空闲连接则直接分配
-- 2. 池中无空闲连接且未达上限，创建新连接
-- 3. 池中无空闲连接且已达上限，等待直到超时
-- 4. 连接 Close() 时归还池中复用，而非真正关闭
-- 5. 池会定期检测并移除失效连接

-- 常见问题：
-- 连接泄漏：忘记 Close/Dispose 连接
-- 解决：使用 using 语句确保连接释放

-- EF Core 配置连接池
-- builder.Services.AddDbContextPool<AppDbContext>(
--     options => options.UseSqlServer(connStr),
--     poolSize: 128);  -- 默认 128

14. 慢查询如何排查和优化？

-- MySQL 慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 超过 1 秒记录
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- 查看慢查询配置
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

-- 分析慢查询步骤：
-- 1. 打开慢查询日志，收集慢 SQL
-- 2. 使用 EXPLAIN 分析执行计划
-- 3. 检查 type 列（避免 ALL 全表扫描）
-- 4. 检查 Extra 列（避免 Using filesort、Using temporary）
-- 5. 检查 rows 列（预估扫描行数）
-- 6. 针对性添加索引或重写 SQL

-- 常见慢查询模式与优化：

-- 模式1：OR 导致索引失效
-- 差
SELECT * FROM orders WHERE customer_id = 100 OR status = 'pending';
-- 好：使用 UNION
SELECT * FROM orders WHERE customer_id = 100
UNION
SELECT * FROM orders WHERE status = 'pending';

-- 模式2：子查询效率低
-- 差
SELECT * FROM orders WHERE customer_id IN (
    SELECT id FROM customers WHERE city = '北京'
);
-- 好：改用 JOIN
SELECT o.* FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
WHERE c.city = '北京';

-- 模式3：大量数据的 COUNT
-- 差：全表扫描
SELECT COUNT(*) FROM orders WHERE status = 'completed';
-- 好：使用覆盖索引或近似计数
SELECT COUNT(id) FROM orders USE INDEX(idx_status) WHERE status = 'completed';

-- 模式4：深度分页
-- 差
SELECT * FROM orders ORDER BY id LIMIT 10 OFFSET 1000000;
-- 好：游标分页
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 10;

面试高频追问

索引相关追问

Q: 为什么 B+ Tree 适合数据库索引，而不是红黑树或哈希表？
A:
1. B+ Tree 磁盘 IO 友好 — 树高度低（3-4层），每次查询只需 3-4 次 IO
2. 范围查询高效 — 叶子节点链表直接遍历
3. 红黑树 — 树高度为 O(logN)，但因子小（2），树更高，IO 次数多
4. 哈希表 — 等值查询 O(1)，但不支持范围查询和排序

Q: 联合索引的最左前缀原则是什么？
A: 联合索引 (a, b, c) 等效于创建了 (a)、(a,b)、(a,b,c) 三个索引。
   查询条件必须从最左列开始才能使用索引。
   WHERE a = 1 AND b = 2      → 命中 (a, b)
   WHERE a = 1 AND c = 3      → 命中 (a)，c 无法使用索引
   WHERE b = 2 AND c = 3      → 不命中（缺少最左列 a）
   WHERE a > 1 AND b = 2      → 命中 (a)，b 无法使用（a 是范围查询）

Q: 什么时候应该建索引？什么时候不应该？
A:
应该建索引：
- WHERE 条件频繁使用的列
- JOIN 关联的列
- ORDER BY / GROUP BY 的列
- 区分度高的列（如手机号、邮箱）

不应该建索引：
- 区分度低的列（如性别、状态只有几个值）
- 频繁更新的列（索引维护成本高）
- 很少查询的列
- 数据量很小的表（全表扫描更快）