当前位置：首页 > news >正文

面试题：对数据库如何进行优化？

news 2025/9/19 9:44:07

一、引言

数据库优化是软件开发和运维中的核心技能，也是面试中的高频考点。其核心目标是提升查询效率、降低资源消耗、增强系统稳定性。有效的数据库优化需要从设计、索引、查询、存储、配置等多维度进行综合考量，本指南将系统介绍数据库优化的关键思路和实践方法。

二、数据模型设计优化（基础）

1、合理规划表结构

遵循范式与适度反范式：基础设计遵循三大范式减少数据冗余，但根据业务场景可适度反范式化（如订单表冗余商品名称），以减少关联查询开销。
选择合适的数据类型：
用int/bigint存储 ID，避免使用varchar（索引效率低）
用decimal存储金额（避免浮点数精度问题），不使用float/double
用timestamp/datetime存储时间，避免字符串类型
大字段（文本、图片）拆分到单独表（如用户表拆出用户详情表），减少主表 IO 操作

何为数据库三大范式:

数据库的三大范式（Normal Form）是关系型数据库设计中用于减少数据冗余、保证数据一致性和完整性的重要理论基础。它们由 Edgar F. Codd 提出，通常分为第一范式、第二范式和第三范式。以下是三大范式的定义和要求：

第一范式（1NF）：原子性（Atomicity）

定义：表中的每一列都是不可再分的基本数据项，即每个字段都必须是原子的，不能包含多个值或重复的组。
目标：消除重复组，确保每列的原子性。
示例：
- ❌ 不符合1NF：学生(学号, 姓名, 选修课程)，其中“选修课程”是一个列表，如“数学, 英语”。
- ✅ 符合1NF：将“选修课程”拆分为多行，每行只包含一门课程。

第二范式（2NF）：完全依赖（Full Functional Dependency）

前提：满足第一范式。
定义：表中的所有非主键字段都必须完全依赖于整个主键，而不是主键的某一部分。
适用场景：主要针对复合主键的情况。
目标：消除部分函数依赖。
示例：
- ❌ 不符合2NF：成绩(学号, 课程号, 学生姓名, 课程名, 分数)，主键是（学号, 课程号）。但“学生姓名”只依赖于“学号”，“课程名”只依赖于“课程号”，存在部分依赖。
- ✅ 符合2NF：拆分为学生(学号, 姓名)、课程(课程号, 课程名)、成绩(学号, 课程号, 分数)。

第三范式（3NF）：消除传递依赖（Transitive Dependency）

前提：满足第二范式。
定义：表中的非主键字段之间不能存在传递依赖，即非主键字段必须直接依赖于主键，而不能依赖于其他非主键字段。
目标：消除传递函数依赖。
示例：
- ❌ 不符合3NF：学生(学号, 姓名, 班级, 班主任)，其中“班主任”依赖于“班级”，而“班级”依赖于“学号”，存在传递依赖。
- ✅ 符合3NF：拆分为学生(学号, 姓名, 班级) 和 班级(班级, 班主任)。

总结

范式	要求
1NF	字段原子性，每列不可再分
2NF	非主键字段完全依赖于主键（消除部分依赖）
3NF	非主键字段之间无传递依赖

2、拆分大表

垂直分表：按字段冷热拆分，如用户表拆分为 "基本信息表"（高频访问字段）和 "详细信息表"（低频访问字段）
水平分表：按规则拆分数据，适用于千万级以上规模表，常见拆分方式包括：
按用户 ID 哈希拆分
按时间范围拆分（如订单表按月份拆分）
按地区 / 业务线拆分

三、索引优化（核心）

1、创建合适的索引

主键索引：每张表必须设置主键（InnoDB 默认使用聚簇索引），推荐使用自增 ID（避免页分裂）
联合索引：遵循最左前缀原则（如(a,b,c)索引可命中a、a+b、a+b+c的查询，无法命中b、b+c），将高频查询字段放在左侧
覆盖索引：索引包含查询所需所有字段（如select a,b from t where a=1，创建(a,b)索引可避免回表查询）

最左前缀原则

在数据库中，最左前缀原则（Most Left Prefix Principle）是针对复合索引（Composite Index）在查询时如何被有效利用的一个重要规则。它决定了查询语句能否使用某个复合索引进行高效检索。

例如：创建一个符合索引

CREATE INDEX idx_name ON users (last_name, first_name, age);

最左前缀原则：MySQL（或其他关系型数据库）在使用复合索引时，只能从索引的最左边的列开始匹配，并且连续地使用索引中的列（可以跳过后面的列，但不能跳过中间的列），否则索引可能失效。
也就是说，查询条件中必须包含复合索引的最左边的一个或多个连续列，才能使用该索引。

假设我们有复合索引：（A，B，C）

以下查询可以使用索引：

查询条件	是否使用索引	说明
`WHERE A = 1`	✅ 是	使用了最左列 A
`WHERE A = 1 AND B = 2`	✅ 是	使用了 A 和 B（连续最左）
`WHERE A = 1 AND B = 2 AND C = 3`	✅ 是	完整使用了索引
`WHERE A = 1 AND C = 3`	⚠️ 部分使用	可以使用 A，但 C 无法使用（跳过了 B）
`WHERE B = 2 AND C = 3`	❌ 否	没有从最左开始，索引失效
`WHERE A > 1 AND B = 2`	⚠️ 部分使用	A 可用于范围查找，但 B 通常无法再使用索引（范围查询后中断）

⚠️ 注意：一旦遇到范围查询（如 >, <, BETWEEN, LIKE 'abc%'），后面的列就无法再使用索引了。

为什么要有最左前缀原则

因为复合索引本质上是一个有序的B+树结构，其排序规则是：

先按 A 排序
A 相同的情况下，按 B 排序
A 和 B 都相同的情况下，按 C 排序

所以，如果不直接从A开始查，数据库无法利用这种有序性进行查找。

如何利用最左前缀设计索引

将高频查询的列放在前面
将等值查询的列放在范围查询列之前
避免跳过中间列使用后面的列

覆盖索引

即使不完全符合最左前缀，但如果查询的字段全部包含在索引中（即“覆盖索引”），数据库仍可能使用索引扫描（Index Scan），但效率可能不如最左匹配。

2、避免索引失效

不在索引字段上做运算（如where age+1=10）或使用函数（如where substr(name,1,1)='张'）
避免where a is null（多数数据库索引不存储 null 值）
模糊查询避免前缀通配符（如where name like '%三'会全表扫描，where name like '张%'可命中索引）
避免or连接非索引字段（如where a=1 or b=2，若b无索引则全表扫描）
谨慎使用!=、<>、not in（可能导致索引失效，视数据库优化器而定）

3、控制索引数量

索引会降低写入性能（插入 / 更新 / 删除时需维护索引）
单表索引建议不超过 5-8 个
优先为查询频繁的字段建立索引，避免为低频查询字段建索引

四、查询语句优化（日常高频）

1、精简查询字段

避免使用select *，只查询需要的字段（减少 IO 和内存消耗，更容易命中覆盖索引）

2、优化子查询

用join代替子查询（部分数据库对子查询优化较差），例如：

-- 低效：子查询
select * from t1 where id in (select id from t2 where status=1);
-- 高效：join
select t1.* from t1 join t2 on t1.id = t2.id where t2.status=1;

3、避免全表扫描

确保where、group by、order by的字段有索引
使用explain分析执行计划，关注type字段（ALL表示全表扫描，需优化）

4、分页优化

大页数分页（如limit 100000, 10）效率低，可通过 "索引定位" 优化：

-- 低效
select * from t order by id limit 100000, 10;
-- 高效（利用主键索引定位起点）
select * from t where id > (select id from t order by id limit 100000, 1) order by id limit 10;

5、其他细节

避免group by无索引字段（会产生临时表）
避免order by非索引字段（可能导致文件排序）
合理使用union all代替union（union会去重，效率更低，确认无重复时用union all）

五、存储引擎和配置优化

1、选择合适的存储引擎

InnoDB：MySQL默认引擎（5.5版本后）支持事务、行锁、外键，适合写频繁场景（如订单系统）
MyISAM：不支持事务，读性能好，适合读多写少场景（如日志表），目前已基本被 InnoDB 替代

2、数据库配置调优

内存相关参数：
innodb_buffer_pool_size（InnoDB 缓存池，建议设为物理内存的 50%-70%，减少磁盘 IO）
key_buffer_size（MyISAM 索引缓存，适用于 MyISAM 表）
连接数配置：
max_connections（最大连接数，避免连接耗尽）
wait_timeout（空闲连接超时时间，释放资源）
日志优化：
innodb_flush_log_at_trx_commit（1：事务提交即刷盘，安全；0/2：性能更高，可能丢数据，根据业务权衡）