评估数据量增长对索引查询性能的影响，核心是判断索引是否仍高效：一看选择性是否劣化（低于5%–10%需警惕），二查索引深度与i/o路径是否变长（blevel升、leaf_pages翻倍则延迟上升），三验高频查询是否仍走索引且不回表（explain中type降级或rows激增即风险），四查写入放大是否反噬读性能（buffer pool reads上升、高峰期p95延迟升高）。
评估数据量增长对索引查询性能的影响，不能只看“表变大了”，而要聚焦在索引是否还能高效工作。核心是判断：随着行数增加，原本有效的索引会不会退化、失效或拖慢整体响应。
看索引选择性是否随数据增长而劣化
选择性 = 不同值数量 / 总行数。比如用户ID字段，1000万行中999万不同值，选择性≈0.99，建索引效果好；但“状态”字段只有3个取值，选择性≈0.0000003，即使数据从10万涨到1000万，索引依然大概率被优化器忽略。实际中，当某列的选择性低于5%–10%，就要警惕它是否还值得保留索引。
测索引深度与I/O路径是否明显变长
InnoDB主键索引（聚簇索引）高度（blevel）每增加1层，一次点查就多一次磁盘随机读。用以下语句查关键索引的当前结构：
-
MySQL：
SELECT index_name, btree_depth, leaf_pages FROM information_schema.INNODB_INDEX_STATS WHERE table_name = 'your_table'; -
PostgreSQL：
SELECT indexrelname, idx_blks_read, idx_blks_hit FROM pg_statio_user_indexes WHERE relname = 'your_table';
若过去半年内leaf_blocks翻倍但查询QPS未提升，说明索引已开始“胖”得不经济；若blevel从2升到3，单次等值查询延迟可能从0.2ms升至0.8ms以上。
验高频查询是否仍走索引且不回表
数据量翻倍后，原来走索引的WHERE条件，现在是否还在用？是否被迫转为全表扫描？执行EXPLAIN对比扩容前后同一SQL：
- 关注
type是否从ref/range降级为ALL - 检查
key列是否仍显示预期索引名 - 观察
rows预估扫描行数是否激增（如从1万跳到300万） - 若查询只查索引字段（如
SELECT user_id, status FROM orders WHERE status='paid'），确认Extra含Using index（覆盖索引），避免因数据膨胀导致回表开销剧增
查写入放大是否反噬读性能
索引越多，每次INSERT/UPDATE都要更新多个B+树——当单表日增50万行、有6个二级索引时，实际写入IO可能是原始数据的7倍。这会抢占buffer pool、推高page fault率，间接拖慢所有查询。可结合监控看：
- MySQL：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads'是否持续上升 - 慢查日志中，是否出现大量
Writing to net或Sending data阶段延迟，而非Creating sort index - 对比相同查询在低峰期（写入少）和高峰期（写入密集）的P95延迟差异
