摘要：很多MySQL用户常遇到磁盘空间爆满、查询性能卡顿、写入速度变慢，其核心原因往往并非业务数据过多，而是索引冗余、索引占用空间过大。大量项目中存在重复索引、无效索引以及超大字段索引，导致索引空间远超数据空间，严重浪费磁盘和内存资源。本文基于MySQL 5.7 / 8.0，详细讲解如何一键查询数据库及数据表的索引占用空间，精准定位大索引与冗余索引，并提供全套索引瘦身优化方案。这些方法可直接用于生产环境，帮助快速释放磁盘空间，提升数据库整体性能。
一、前言
在MySQL运维与优化过程中，绝大多数开发人员仅关注业务数据的空间占用，却长期忽视了索引空间这一隐形消耗源。
实际生产场景中，许多库表的数据量仅有几GB，但索引占用空间却高达十几GB甚至几十GB，进而引发一系列问题：磁盘空间莫名爆满、数据库备份文件异常庞大、数据插入/更新/删除操作耗时增加、缓冲池命中率下降、查询性能卡顿等。
与常规的库表空间查询不同，本文专门围绕索引空间统计、大索引排查、冗余索引清理进行深度实战讲解，旨在解决索引空间溢出与资源浪费的核心痛点，是MySQL性能优化与磁盘瘦身的核心干货内容。
二、核心认知：为什么索引会占用超大空间？
想要有效优化索引空间，首先需要理解索引空间膨胀的根本原因，从而避免盲目删除索引导致业务异常：
- 冗余索引过多：存在重复索引、前缀包含索引，以及长期未被使用的废弃索引。
- 大字段索引：对TEXT、VARCHAR(2000)、长字符串等字段建立索引，导致单索引体积巨大。
- 联合索引滥用：随意创建多字段联合索引，索引基数大，占用空间极高。
- 索引碎片堆积：表频繁进行增删改操作，索引页产生大量碎片，额外占用磁盘空间。
- 主键索引过大：使用自增主键以外的长字符主键，导致所有二级索引同步膨胀。
行业通用标准：正常表的索引空间应小于或等于数据空间。若索引空间远超数据空间，则必然存在优化空间。
三、实战SQL：查询MySQL索引占用空间（全场景）
以下所有语句兼容MySQL 5.7与8.0，适用于自建MySQL、阿里云RDS、腾讯云RDS等环境，可直接复制执行，精准统计索引占用的磁盘大小。
3.1 查看所有数据库索引总占用空间
全局盘点所有业务库的索引总容量，快速定位索引空间溢出的数据库，适合进行全局巡检：
SELECT TABLE_SCHEMA AS 数据库名, ROUND(SUM(INDEX_LENGTH)/1024/1024,2) AS 索引总空间_MB, ROUND(SUM(INDEX_LENGTH)/1024/1024/1024,3) AS 索引总空间_GB, ROUND(SUM(DATA_LENGTH)/1024/1024,2) AS 数据空间_MB, ROUND((SUM(INDEX_LENGTH)/SUM(DATA_LENGTH))*100,2) AS 索引数据占比_百分比 FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY TABLE_SCHEMA ORDER BY 索引总空间_GB DESC;结果解读
- 索引数据占比越高，代表索引冗余越严重，优化优先级越高。
- 若索引空间超过数据空间的1.5倍，属于严重异常，必须进行优化。
- 快速筛选出全库中索引占用最高的业务库，以便针对性瘦身。
3.2 查询指定库所有表索引大小（精准排查大索引表）
定位问题数据库后，一键查询库内所有表的索引空间、数据空间及空间占比，快速找出索引超大的数据表：
SELECT TABLE_NAME AS 表名, TABLE_ROWS AS 数据行数, ROUND(DATA_LENGTH/1024/1024,2) AS 数据空间_MB, ROUND(INDEX_LENGTH/1024/1024,2) AS 索引空间_MB, ROUND((DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) AS 表总空间_MB, ROUND((INDEX_LENGTH/(DATA_LENGTH+INDEX_LENGTH))*100,2) AS 索引占比_%, ENGINE AS 存储引擎 FROM information_schema.TABLES WHERE TABLE_SCHEMA = '你的数据库名' ORDER BY 索引空间_MB DESC;
3.3 筛选索引异常的风险表（自动过滤问题表）
自定义阈值，自动筛选出索引占比过高的风险表，无需人工排序，即可批量定位优化目标：
SELECT TABLE_NAME AS 风险表名, ROUND(DATA_LENGTH/1024/1024,2) AS 数据空间_MB, ROUND(INDEX_LENGTH/1024/1024,2) AS 索引空间_MB, ROUND((INDEX_LENGTH/DATA_LENGTH)*100,2) AS 索引超数据倍数 FROM information_schema.TABLES WHERE TABLE_SCHEMA = '你的数据库名' AND INDEX_LENGTH > DATA_LENGTH ORDER BY 索引超数据倍数 DESC;
场景用途：批量筛选出索引空间大于数据空间的异常表，是索引瘦身的核心目标。
四、进阶实战：精准查询单条索引占用空间
以上语句只能统计整表索引总空间，无法查看单条索引的具体大小。若要精准删除无用的大索引，需要了解每张表中具体的索引名称、字段及占用空间。
MySQL没有直接查询单索引大小的原生语句，但可以通过系统表结合规则进行精准分析，并搭配以下命令查看表的所有索引结构：
# 查看表所有索引详情 SHOW INDEX FROM 你的表名;
结合上表统计的整表索引空间，可以精准判断：长字段索引、联合索引、废弃索引是空间占用的主要元凶。
五、核心技能：MySQL冗余索引排查方法
冗余索引是索引空间浪费的首要原因。许多项目存在大量重复、可替代的索引，它们只会占用磁盘空间、拖慢写入操作，对查询没有任何帮助。
5.1 冗余索引判定规则
- 前缀冗余：已有索引(a,b,c)，单独建立的索引(a)或(a,b)属于冗余索引。
- 重复索引：完全相同的字段索引被重复创建。
- 无效索引：长期未被SQL语句使用的索引。
- 低效索引：区分度极低的字段索引（如状态、性别等字段）。
5.2 查询数据库未使用的索引（精准清理）
通过性能模式查询长期闲置的索引，这类索引通常可以安全删除，从而释放空间：
SELECT OBJECT_NAME AS 表名, INDEX_NAME AS 未使用索引名 FROM performance_schema.table_io_waits_summary_by_index_usage WHERE INDEX_NAME IS NOT NULL AND COUNT_STAR = 0 AND OBJECT_SCHEMA = '你的数据库名';
六、MySQL索引空间瘦身优化方案（生产可用）
针对索引空间过大、冗余过多的问题，以下整理出4套生产级优化方案，按安全优先级排序，可零风险释放磁盘空间。
6.1 删除所有冗余、未使用索引（首选）
清理系统检测出的未使用索引以及前缀冗余索引，无业务风险、效果最明显，是索引瘦身的首选方案。
删除语法：DROP INDEX 索引名 ON 表名;
6.2 优化大字段索引
禁止对超长字符串字段建立全字段索引，优化方案如下：
- 使用前缀索引：仅对字段前10-20位字符建立索引，大幅缩减索引体积。
- 废弃无效的长字段索引，改用全文索引或模糊查询替代。
6.3 合并重复联合索引
将多张表中零散的单字段索引及短联合索引，合并为最优联合索引，从而减少索引数量，兼顾查询性能与空间占用。
6.4 清理索引碎片
索引长期进行增删改操作会产生大量碎片，导致索引空间虚高。可在低峰期执行优化：
OPTIMIZE TABLE 表名;
执行后可回收索引中的空闲碎片，降低磁盘占用，同时提升索引检索效率。
七、索引优化避坑指南（生产必看）
- 禁止盲目删索引：删除前务必确认该索引未被业务SQL使用，避免导致查询性能暴跌。
- 主键索引不可删：主键索引是InnoDB聚簇索引的核心，删除会导致表结构异常。
- 业务高峰禁止操作：删除或重建索引会锁表，必须在凌晨低峰期执行。
- 优先清理冗余，再做结构优化：先清理无效索引以快速释放空间，再进一步优化索引结构。
八、总结
MySQL磁盘空间爆满、性能卡顿，索引冗余膨胀是极易被忽略的核心诱因。相比清理业务数据，优化索引空间零业务损耗、见效快，是数据库运维瘦身的最优方案。
本文提供的全套SQL可一键统计全库及单表的索引占用空间，精准定位异常大索引和冗余索引，配合成熟的索引瘦身方案，能快速释放大量磁盘空间，同时提升数据库读写性能。建议所有运维人员定期执行索引空间巡检，从根源上解决索引空间浪费问题。
