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

013、数据库性能优化：索引、查询与连接池

news 2026/5/12 21:34:53

013、数据库性能优化：索引、查询与连接池

一、从一次慢查询说起

上周排查一个线上问题，接口响应时间从平均 50ms 飙到 2 秒以上。打开慢查询日志，抓到一条 SQL：

SELECT*FROMorder_detailWHEREuser_id=10086ANDstatus=1ANDcreate_time>'2024-01-01'ORDERBYupdate_timeDESCLIMIT20;

表里有 300 万条数据，这条查询居然扫了 280 万行。第一反应是索引问题，一看表结构，果然只在id上建了主键索引。问题就出在这里——没有为查询条件建立合适的索引。

二、索引不是越多越好

很多人觉得索引能加速查询，就拼命建索引。我见过一张表建了 15 个索引，写入速度慢得像蜗牛。索引的本质是用空间换时间，每个索引都是一棵 B+ 树，写入时要维护所有索引树。

踩坑案例：曾经在status字段上单独建索引，查询依然慢。后来明白，status只有 0/1 两种值，区分度太低，MySQL 优化器可能直接忽略这个索引。

正确姿势：对上面那条慢查询，我建的是联合索引：

ALTERTABLEorder_detailADDINDEXidx_user_status_time(user_id,status,create_time);

注意字段顺序：

user_id放第一，因为等值查询，区分度高
status放第二，虽然区分度低，但能利用索引过滤
create_time放最后，用于范围查询

别这样写：

-- 顺序乱放，索引可能失效ADDINDEXidx_time_status_user(create_time,status,user_id);

三、查询优化的几个细节

1. 避免 SELECT *

-- 坏习惯：读所有字段SELECT*FROMlarge_tableWHERE...-- 好习惯：只取需要的SELECTid,name,statusFROMlarge_tableWHERE...

多一个字段就可能多一次回表操作，尤其 TEXT/BLOB 字段。

2. 小心 JOIN 陷阱

-- 大表 JOIN 大表，性能灾难SELECT*FROMtable_a aJOINtable_b bONa.id=b.a_idWHEREa.create_time>'2024-01-01';-- 先过滤再 JOINSELECT*FROM(SELECTid,nameFROMtable_aWHEREcreate_time>'2024-01-01')aJOINtable_b bONa.id=b.a_id;

3. 分页的坑

-- 深度分页，越往后越慢SELECT*FROMtableLIMIT1000000,20;-- 优化：记住上一页最后一条的 idSELECT*FROMtableWHEREid>1000000LIMIT20;

四、连接池：别小看这池子水

早期项目直接每次查询创建连接，QPS 到 500 就报Too many connections。后来上了连接池，稳定支撑 3000+ QPS。

关键参数配置（以 HikariCP 为例）：

# 这里踩过坑：maxLifetime 设太短会导致连接频繁重建hikari:maximum-pool-size:20# 根据业务调整，不是越大越好minimum-idle:10max-lifetime:1800000# 30分钟，别低于 30sconnection-timeout:3000# 获取连接超时时间idle-timeout:600000# 空闲连接超时

监控指标要看：

活跃连接数
空闲连接数
等待获取连接的线程数
连接创建/销毁频率

五、ORM 的甜与苦

用 Django ORM 或 SQLAlchemy 确实方便，但生成的 SQL 可能很蠢。一定要开启 query log，定期检查。

案例：

# 这样写会产生 N+1 查询users=User.objects.filter(age__gt=20)foruserinusers:print(user.profile.address)# 每次循环都查一次 profile# 优化：使用 select_relatedusers=User.objects.select_related('profile').filter(age__gt=20)