phpmyadmin中cardinality显示为空需先确认表引擎、权限及非临时表；若show index中也为null，则执行analyze table强制更新统计，而非optimize table；innodb基数为采样估算，精度受innodb_stats_persistent_sample_pages影响。
phpMyAdmin里看不到索引Cardinality？先确认表引擎和权限
MyISAM和InnoDB都支持显示Cardinality，但前提是：表不是临时表、没有被锁死、且当前用户有SHOW INDEXES权限。常见现象是点开“结构”页后，“Cardinality”列全为NULL或空白——这通常不是phpMyAdmin bug，而是MySQL没统计或拒绝提供。执行SHOW INDEX FROM `table_name`;在SQL标签页手动查，如果返回结果里Cardinality也是NULL，说明底层未更新统计信息，不是界面问题。
InnoDB默认延迟更新基数（由innodb_stats_auto_recalc控制），小表可能长期不刷新；MyISAM则依赖myisam_stats_method和是否运行过ANALYZE TABLE。别急着重装或换工具，先看下一步。
强制刷新Cardinality：用ANALYZE TABLE而不是OPTIMIZE
OPTIMIZE TABLE会重建表并释放碎片，但它对InnoDB的基数更新不可靠（尤其在innodb_file_per_table=OFF时可能跳过统计）。真正稳定触发基数重算的是ANALYZE TABLE——它只采样并更新索引统计，不移动数据，速度快、影响小。
- 在phpMyAdmin的SQL标签页执行：
ANALYZE TABLE `your_database`.`your_table`; - 执行后立刻切回“结构”页，刷新页面，
Cardinality列通常几秒内就更新 - 对分区表需指定分区：
ANALYZE TABLE `t` PARTITION(p0); - 批量操作可写脚本，但注意
ANALYZE会加MDL读锁，高并发写入场景避开业务高峰
Cardinality数值不准？检查采样率与数据分布
InnoDB的基数不是精确计数，而是基于随机采样估算（默认采样innodb_stats_persistent_sample_pages页，默认20页）。如果表中某列值高度倾斜（比如100万行里99万是'active'），估算值会严重失真——这时看到Cardinality = 2不代表只有两个唯一值，而是采样结果太片面。
调高采样页数能改善精度，但代价是ANALYZE变慢：
- 临时生效（当前会话）：
SET SESSION innodb_stats_persistent_sample_pages = 100; - 永久生效需改MySQL配置文件，设
innodb_stats_persistent_sample_pages = 100并重启 - MyISAM用
myisam_stats_method = NULLS_UNEQUAL可避免把NULL当同一值处理
别迷信Cardinality数字本身，它只用于优化器选索引。即使显示为1，只要EXPLAIN里key列用了这个索引，就说明实际有效。
重建索引不能靠phpMyAdmin点击“重新创建”
phpMyAdmin“结构”页的“重新创建”按钮本质是DROP + CREATE INDEX，但它不保证重建后立即更新Cardinality——尤其InnoDB可能缓存旧统计。更可靠的做法是重建后紧跟ANALYZE TABLE。
如果索引已损坏（如SELECT返回重复/丢失数据，或CHECK TABLE报错），才需要真正重建：
- InnoDB：用
ALTER TABLE `t` ENGINE=InnoDB;（会重建整个表，含所有索引） - 仅重建单个索引（5.7+）：
ALTER TABLE `t` DROP INDEX `idx_name`, ADD INDEX `idx_name` (`col`); - MyISAM：
REPAIR TABLE `t` QUICK;比ANALYZE更能修复物理索引文件
重建后务必执行ANALYZE TABLE，否则Cardinality可能仍沿用旧快照——这是最容易被忽略的一步。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
