表格列表查询很慢，技术和业务两侧怎么解
和第 11 题慢 SQL 相关，但更偏 后台表格、多条件筛选、导出 这类产品场景。面试官想听你能和技术、产品一起算账，不只改
my.cnf。
题目
有一个表格查询很慢，怎么解决？技术角度和业务角度都可以说。
参考答案（口述要点）
技术：索引、SQL 改写、分页、缓存、读写分离、搜索引擎、异步导出
业务：减字段、缩时间范围、默认只查近 30 天、导出走任务、权限过滤减少数据量
详细解析：技术侧
1. 列表接口典型问题
- 前端传 10 个筛选项 全走
LIKE '%xx%'→ 索引失效 - 一次
SELECT *拉几万行到内存再分页 - 关联四五张表没索引
2. 可落地方案
-- 联合索引顺序：等值在前，范围在后
CREATE INDEX idx_order_status_time ON orders(status, create_time, id);
-- 只查列表需要的列
SELECT id, order_no, status, amount, create_time
FROM orders
WHERE status = ? AND create_time >= ?
ORDER BY create_time DESC
LIMIT 20;3. 产品形态
| 手段 | 说明 |
|---|---|
| 游标/Seek 分页 | 用 id > lastId 代替大 offset |
| Redis 缓存第一页 | 首页热点，TTL 短 |
| ES / ClickHouse | 复杂筛选、全文检索 |
| 异步导出 | 超过 1 万行走 MQ 生成文件，避免拖垮接口 |
@PostMapping("/export")
public Result<String> export(@RequestBody Query q) {
String taskId = exportService.submit(q); // 投递 MQ
return Result.ok(taskId); // 前端轮询下载链接
}详细解析：业务侧
- 默认时间范围：订单列表默认近 3 个月，老数据单独「历史订单」入口
- 必填筛选：数据量大时要求选状态或单号再查，避免「空条件刷全表」
- 字段展示：表格只显示 8 列，详情再点开，减少 JOIN
- 权限裁剪：销售只看自己客户，SQL 带
sales_id = ?，行数天然变小- 导出限制：单次最多 5 万行，更大要审批或离线数仓
和 PM 沟通时可以说：「不是数据库慢，是无条件查询成本就是 O(全表)」，推动改交互比硬优化便宜。
代码与实践（组合拳）
- 接口 超过 3s 告警，慢 SQL 自动进工单
- 统计报表 T+1 进宽表，别实时扫交易表
- 前端 防抖 + 禁止重复点查询
写在最后
表格慢往往是 交互设计 + 数据量 + SQL 叠在一起。面试技术方案说完，补两句业务收敛，会显得你能和产品协作，不是只会 DBA 那套。
创作不易，转载请注明出处和作者。