MySQL中联表查询优化的实战指南

 更新时间:2026年06月03日 09:18:57   作者:元宝骑士  
这篇文章主要介绍了MySQL在处理多表关联查询性能问题时的索引优化策略,重点介绍了小表驱动的联合索引设计原则,以及覆盖索引和定期分析的重要性,通过实际案例展示了优化前后性能的显著提升

一、问题背景

最近遇到一个生产环境的多表关联查询性能问题,主表需要同时关联两个表:一个是配置小表(约1200行),一个是业务大表(约12万行)。查询响应时间从毫秒级逐渐恶化到秒级,急需优化。

二、表结构模拟

1. 小表 - 配置表(约1200行)

    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    invoicing_group_no VARCHAR(50) NOT NULL COMMENT '开票组编号',
    group_name VARCHAR(100) COMMENT '组名称',
    status TINYINT DEFAULT 1 COMMENT '状态 1-启用 0-禁用',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    KEY idx_status (status)
) COMMENT='开票组配置表,约1200行数据';

2. 大表 - 审批主表(约12万行)

    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    claim_approval_no VARCHAR(50) NOT NULL COMMENT '审批单号',
    approval_status VARCHAR(20) COMMENT '审批状态',
    amount DECIMAL(12,2) COMMENT '审批金额',
    applicant_id BIGINT COMMENT '申请人ID',
    apply_date DATE COMMENT '申请日期',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE KEY uk_approval_no (claim_approval_no),
    KEY idx_apply_date (apply_date),
    KEY idx_applicant (applicant_id)
) COMMENT='审批主表,约12万行数据';

3. 主表 - 业务主表(约100万行)

    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    business_no VARCHAR(50) NOT NULL COMMENT '业务单号',
    invoicing_group_no VARCHAR(50) NOT NULL COMMENT '关联开票组',
    claim_approval_no VARCHAR(50) COMMENT '关联审批单号',
    amount DECIMAL(10,2) COMMENT '金额',
    status TINYINT DEFAULT 0 COMMENT '状态 0-待处理 1-已处理 2-已取消',
    create_user_id BIGINT COMMENT '创建人',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY uk_business_no (business_no),
    KEY idx_status (status),
    KEY idx_create_user (create_user_id),
    KEY idx_created_at (created_at)
) COMMENT='业务主表,约100万行数据,需关联小表和大表';

三、查询场景

典型的联表查询:

SELECT m.*, g.group_name, a.approval_status, a.amount as approval_amount
FROM main_table m
JOIN group_table g ON m.invoicing_group_no = g.invoicing_group_no
JOIN approval_table a ON m.claim_approval_no = a.claim_approval_no
WHERE m.invoicing_group_no = 'GROUP001'
  AND m.status = 1
  AND g.status = 1
ORDER BY m.created_at DESC
LIMIT 100;

四、单表查询索引设计规则

在考虑联表索引前,先回顾单表查询索引的基本原则:

1.WHERE条件优先

  • 最常用于WHERE条件的字段建索引
  • 联合索引中,区分度高的放前面
  • 示例:INDEX(status, created_at)用于 WHERE status=1 ORDER BY created_at

2.等值查询在前,范围查询在后

INDEX(status, created_at)  -- 适合 WHERE status=1 AND created_at > '2024-01-01'

-- 差索引:范围在前,等值在后  
INDEX(created_at, status)  -- 范围查询会中断索引使用

3.ORDER BY和GROUP BY优化

  • 排序字段尽量放入索引
  • 避免filesort,利用索引天然有序
  • 示例:INDEX(status, created_at)天然支持 ORDER BY created_at

4.覆盖索引原则

  • 包含所有查询字段,避免回表
  • 示例:SELECT id, status, created_at可用 INDEX(status, created_at, id)

5.前缀索引技巧

  • 字符串字段可只索引前N个字符
  • 示例:INDEX(column_name(20))
  • 需平衡选择性和存储空间

五、联表查询索引优化方案

支持小表驱动的联合索引(推荐)

ALTER TABLE main_table ADD INDEX idx_group_approval (invoicing_group_no, claim_approval_no, status, created_at);

-- 小表:关联字段索引
ALTER TABLE group_table ADD INDEX idx_invoicing_group (invoicing_group_no, status);

-- 大表:关联字段索引
ALTER TABLE approval_table ADD INDEX idx_claim_approval (claim_approval_no);

为什么这个顺序?

  • invoicing_group_no在前:支持小表(1200行)快速过滤
  • claim_approval_no第二:过滤后结果关联大表(12万行)
  • statuscreated_at:覆盖查询条件和排序

六、执行计划对比

通过EXPLAIN分析两种方案:

方案1执行计划(小表驱动)

2. SIMPLE    m    ref    idx_group_approval    idx_group_approval 52    const,const    2500  100.00
3. SIMPLE    a    eq_ref idx_claim_approval    idx_claim_approval 52    m.claim_approval_no 1    100.00

优点:小表先过滤,结果集小,大表关联效率高

方案2执行计划

2. SIMPLE    g    eq_ref idx_invoicing_group    idx_invoicing_group 52    m.invoicing_group_no 1    100.00
3. SIMPLE    a    eq_ref idx_claim_approval    idx_claim_approval 52    m.claim_approval_no 1    100.00

注意:虽然执行顺序不同,但两者性能差异不大,取决于具体数据分布

七、优化建议总结

  1. 联合索引顺序:不是越大表的外键越靠前,要看优化器的执行策略
  2. 小表驱动原则:多数情况下,优化器会优先用小表过滤
  3. 覆盖索引:尽量让索引包含所有查询字段
  4. 定期分析:使用ANALYZE TABLE更新统计信息
  5. 监控调整:通过慢查询日志持续优化

关键结论:在"小表驱动大表"的场景中,联合索引应该把"小表关联字段"放在前面,即使它的区分度较低。这能最大化支持优化器的执行策略,获得最佳性能。

八、性能验证

优化后性能对比:

  • 优化前:2.3秒
  • 优化后:0.15秒
  • 提升:15倍

这个案例再次证明,理解MySQL优化器的工作原理,比单纯记忆规则更重要。结合实际数据分布和查询模式,才能做出最佳的索引设计决策。

到此这篇关于MySQL中联表查询优化的实战指南的文章就介绍到这了,更多相关MySQL联表查询内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • MySQL 的模块不能安装的解决方法

    MySQL 的模块不能安装的解决方法

    这篇文章主要介绍了MySQL 的模块不能安装的解决方法的相关资料,需要的朋友可以参考下
    2015-07-07
  • MySQL低权限提权的方法

    MySQL低权限提权的方法

    在MySQL中,低权限提权是一种常见的需求,低权限用户通过利用漏洞、存储过程、用户定义函数(UDF)和触发器(Trigger)等技术手段进行权限提升,本文就来介绍一下,感兴趣的可以了解一下
    2024-09-09
  • mysql函数IFNULL使用的及注意事项说明

    mysql函数IFNULL使用的及注意事项说明

    这篇文章主要介绍了mysql函数IFNULL使用的及注意事项说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2023-11-11
  • windows下Mysql多实例部署的操作方法

    windows下Mysql多实例部署的操作方法

    这篇文章主要介绍了windows下Mysql多实例部署,需要部署Mysql多个实例,原理很简单,多个mysql服务运行使用不同的配置及数据管理,需要的朋友可以参考下
    2022-09-09
  • windows系统mysql压缩包版本安装过程

    windows系统mysql压缩包版本安装过程

    这篇文章主要介绍了windows系统mysql压缩包版本安装过程,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2023-03-03
  • mysql中between的用法及说明

    mysql中between的用法及说明

    这篇文章主要介绍了mysql中between的用法及说明,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-07-07
  • MySQL常用命令与内部组件及SQL优化详情

    MySQL常用命令与内部组件及SQL优化详情

    这篇文章主要介绍了MySQL常用命令与内部组件及SQL优化详情,文章围绕主题展开详细的内容介绍,具有一定的参考价值,需要的朋友可以参考一下
    2022-07-07
  • mysql root密码的重设方法(亲测可用)

    mysql root密码的重设方法(亲测可用)

    这篇文章主要介绍了如何重设mysql root密码,需要的朋友可以参考下
    2014-02-02
  • MySQL 问题汇总及常见解决方式

    MySQL 问题汇总及常见解决方式

    文章总结了MySQL使用中常见的问题及解决方案,包括连接与访问问题、性能优化、数据操作与语法问题、服务与配置问题和存储引擎相关问题,主要建议先查日志定位问题,日常做好配置优化和备份,遇到复杂问题结合工具进行分析,感兴趣的朋友跟随小编一起看看吧
    2017-09-09
  • mysql之查询两个时间段是否有交集的情况

    mysql之查询两个时间段是否有交集的情况

    这篇文章主要介绍了mysql之查询两个时间段是否有交集的情况,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2023-08-08

最新评论