phpMyAdmin中索引基数（Cardinality）仅显示MySQL缓存的统计值，非实时更新；需执行ANALYZE TABLE命令强制刷新，再回结构页查看，否则可能严重失真并误导优化器选错执行计划。
索引基数在phpMyAdmin里根本看不到实时值
phpMyAdmin 不提供索引基数（Cardinality）的动态计算或可视化图表，它只在「结构」页的索引列表中显示 Cardinality 列——但这个值来自 MySQL 的统计信息缓存（INFORMATION_SCHEMA.STATISTICS），可能严重滞后，尤其在数据频繁变更后。MySQL 8.0+ 默认启用 innodb_stats_auto_recalc=ON，但触发仍依赖采样阈值（如表变更超 10%），不是实时更新。
常见错误现象：Cardinality 显示为 0 或远低于实际唯一值数量，导致你误判索引选择性；或者修改数据后刷新页面，该值纹丝不动。
- 查看位置：进入数据表 → 「结构」页 → 滚动到底部「索引」区域，看
Cardinality列 - 该值不可编辑，也不能“刷新”它——phpMyAdmin 没提供强制更新入口
- 若需真实基数，必须手动触发统计更新（见下一条）
用 SQL 强制更新索引统计信息才能让 Cardinality 准确
只有执行 ANALYZE TABLE，MySQL 才会重新采样并更新 Cardinality 值。phpMyAdmin 支持直接运行该语句，这是修正基数显示的唯一可靠方式。
使用场景：批量导入/删除数据后、新建索引后、发现执行计划异常（如本该走索引却全表扫描）时。
立即学习“PHP免费学习笔记（深入）”；
- 在 phpMyAdmin 中切换到「SQL」页，执行：
ANALYZE TABLE `your_table_name`;
- 支持多表：
ANALYZE TABLE `users`, `orders`, `products`;
- 注意权限：用户需有
PROCESS或SELECT权限（通常 phpMyAdmin 用户已具备） - 执行后立即返回结果，再回到「结构」页刷新，
Cardinality值才会更新
Cardinality 数值本身不能直接修改
索引基数是 MySQL 内部统计结果，不是可配置项。不存在「编辑基数」按钮，也不该尝试伪造或覆盖该值——任何试图绕过 ANALYZE TABLE 直接写入 INFORMATION_SCHEMA 的操作都会失败（该库为只读视图）。
容易踩的坑：
- 误以为 phpMyAdmin 的「编辑索引」功能能调基数——其实只能改索引名、字段顺序、类型（UNIQUE / FULLTEXT 等）
- 在「操作」页勾选「重新创建表」或「优化表」，它们不等价于
ANALYZE TABLE：OPTIMIZE TABLE会重建表并附带分析，但开销大、锁表久，没必要只为更新基数 - 用
SHOW INDEX FROM table查到的Cardinality和 phpMyAdmin 显示一致，但同样滞后——根源都在统计缓存
真正影响查询性能的是基数质量，不是 phpMyAdmin 显示是否好看
phpMyAdmin 里的数字只是参考。决定索引是否被选用的关键，是优化器对基数的评估是否接近真实分布。如果 Cardinality 长期不准，EXPLAIN 可能给出错误预估，进而选错执行计划。
所以比盯着 phpMyAdmin 更有效的是：
- 定期对高频更新的大表执行
ANALYZE TABLE（例如凌晨低峰） - 用
EXPLAIN SELECT ...观察key和rows字段，比看Cardinality更直接 - 检查
innodb_stats_persistent是否开启（MySQL 5.6.2+ 默认 ON），它让统计持久化，避免重启丢失
别花时间找“可视化基数图表”插件——phpMyAdmin 没这功能，MySQL 本身也不提供实时基数流式输出。准不准，靠 ANALYZE TABLE 和 EXPLAIN 配合验证就够了。
