MySQL NDB集群带索引查询仍全表扫描的性能优化求助

首先得说，NDB Cluster的索引行为和InnoDB有不少差异，这很可能是你遇到问题的核心原因。咱们一步步来排查和解决：

1. 先确认执行计划，定位问题根源 #

先跑这条命令看执行计划：

EXPLAIN SELECT CI FROM MyTable WHERE CI = 9787988;

重点关注这几个字段：

• type：如果显示ALL，那确实是全表扫描；如果是ref或eq_ref，说明索引在正常工作。
• key：这里应该显示你创建的nidx_MyTable_CI，如果是NULL，说明优化器没选中这个索引。
• Extra：如果出现Using index，说明用了覆盖索引（不需要回表取数据），这是最优情况。

2. 排查索引本身的问题 #

索引类型是否适配NDB的等值查询 #

NDB Cluster中，HASH索引对单值等值查询的效率远高于BTREE——BTREE更适合范围查询（比如> < BETWEEN）。你当前创建的是BTREE索引，试试换成HASH索引：

DROP INDEX nidx_MyTable_CI ON MyTable;
CREATE INDEX nidx_MyTable_CI ON MyTable(CI) USING HASH;

换完后再跑查询和EXPLAIN，看是否能用上索引。

检查索引基数和统计信息 #

如果CI列的重复值极高（比如大部分行的CI都是同一个值），优化器会认为全表扫描比索引查找更高效（因为索引需要先定位再回表，即使是覆盖索引，NDB的索引访问也有额外开销）。

用这条命令查看索引基数：

SHOW INDEX FROM MyTable WHERE Key_name = 'nidx_MyTable_CI';

看Cardinality（基数）列，如果这个值远低于表行数的10%，说明重复率太高。

另外，NDB的普通ANALYZE TABLE更新统计信息的效果可能不如InnoDB彻底，试试执行：

ANALYZE TABLE MyTable PERSISTENT FOR ALL;

这个命令会强制更新NDB的持久化统计信息，帮助优化器做出正确决策。

重建索引解决潜在损坏/碎片 #

有时候索引可能因为集群同步问题出现碎片或损坏，删除重建试试：

DROP INDEX nidx_MyTable_CI ON MyTable;
-- 根据查询场景选HASH或BTREE
CREATE INDEX nidx_MyTable_CI ON MyTable(CI) USING HASH;

3. 检查数据类型匹配问题 #

如果CI列是VARCHAR类型，而你查询用的是数字9787988，MySQL会做隐式类型转换——把CI列的所有值转换成数字再匹配，这会直接导致索引失效，触发全表扫描。

确认CI的类型，如果是字符串，把查询改成：

SELECT CI FROM MyTable WHERE CI = '9787988';

4. 检查NDB集群的内存配置 #

NDB是内存型存储引擎，数据和索引都要放在内存里。如果数据节点的内存不足，索引会被swap到磁盘，导致访问速度暴跌，优化器可能干脆选择全表扫描。

用NDB管理工具ndb_mgm连接集群，执行SHOW STATUS查看内存使用情况，重点看DataMemory和IndexMemory的使用率。如果内存不够，需要修改my.cnf（或ndb_mgmd配置文件）中的对应参数，然后重启数据节点。

5. 排查版本bug #

你用的是NDB 7.5.9，这个版本属于比较旧的7.5系列，可能存在二级索引无法被正确选择的bug。建议查看官方的bug修复日志，或者考虑升级到7.5系列的最新稳定版（比如7.5.35），新版本通常会修复不少索引相关的问题。

最后，如果FORCE INDEX依然无效 #

如果执行SELECT CI FROM MyTable FORCE INDEX(nidx_MyTable_CI) WHERE CI = 9787988;还是全表扫描，那大概率是优化器认为全表扫描的成本确实更低。这时候可以用EXPLAIN FORMAT=JSON SELECT ...查看优化器的详细成本计算，看看它为什么做出这个选择——比如是因为返回的行数太多，还是索引访问的成本过高。

内容的提问来源于stack exchange，提问作者Rajesh