不会。复合索引本身不占用Buffer Pool，真正消耗内存的是被缓存的索引页；索引越宽越多，单页存储记录越少，所需索引页越多，间接挤占Buffer Pool中数据页空间。
复合索引字段过多会直接挤占Buffer Pool吗？
不会。复合索引本身不“占用”Buffer Pool内存，真正吃内存的是被缓存的索引页数据——但索引越宽、越多，InnoDB加载和维护它的成本就越高，间接加剧Buffer Pool压力。比如一个包含5个VARCHAR(255)字段的复合索引，单页能存的记录数大幅减少，同样100万行数据，可能需要多出30%的索引页才能装下，这些页全进Buffer Pool后，就会挤占原本留给数据页的空间。
哪些复合索引设计会显著抬高Buffer Pool负载？
以下情况会让索引“变胖”，加重缓存负担：
-
ALTER TABLE t ADD INDEX idx_wide (user_name, email, phone, address, created_at)：字段全是长字符串，索引B+树节点体积膨胀，页分裂更频繁，buffer pool中缓存的索引页数量激增 - 重复覆盖同一查询路径的索引，如同时存在
idx_a_b和idx_a_b_c：MySQL可能只用到前者，后者纯属冗余，却仍要加载、维护、刷脏 - 在低选择性字段（如
status ENUM('pending','paid','shipped')）上强行前置：导致B+树深度增加、范围扫描效率下降，更多页被拉入buffer pool却利用率极低
怎么判断当前复合索引是否“过长”或“冗余”？
别靠感觉，用这两个命令实测：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
查索引实际宽度：
SELECT table_name, index_name, SUM(stat_value) * 16384 AS size_bytes FROM mysql.innodb_index_stats WHERE database_name = 'your_db' AND stat_name = 'size' GROUP BY table_name, index_name ORDER BY size_bytes DESC;
看哪些索引占空间异常大；再结合使用率：
SELECT object_schema, object_name, index_name, count_read, count_write FROM performance_schema.table_io_waits_summary_by_index_usage WHERE index_name IS NOT NULL ORDER BY count_read + count_write DESC LIMIT 10;
如果某个宽索引 count_read 为 0 或远低于其他索引，基本可判定是“僵尸索引”，该删。
优化时最容易忽略的细节
很多人删完宽索引就以为完事了，其实Buffer Pool不会立刻释放对应内存——InnoDB不会主动踢出冷页，得等LRU淘汰或重启。更关键的是：删除索引后必须执行 ANALYZE TABLE t，否则优化器可能还在用旧的统计信息生成执行计划，甚至误判为“没索引可用”而走全表扫描，反而把更多数据页拖进Buffer Pool。
另外，innodb_buffer_pool_size 不是越大越好，它和索引宽度是联动关系：你建了个12GB的巨型索引，又把buffer pool设成48GB，结果就是大量内存被低效索引页占据，数据页命中率反而跌破90%。真正的平衡点，永远取决于 free -h 的 available 值和真实工作集大小，不是纸上谈兵的百分比。
