存在严重行链接需同时满足v$segment_statistics中chain row计数持续增长且analyze table validate structure cascade显示chained_rows超总行数1%；二者分别反映动态访问异常与静态物理分布问题。
直接看 v$segment_statistics 里 chain row 计数是否持续增长，再结合 analyze table ... validate structure cascade 输出的 chained_rows 行数 —— 这两个信号同时出现，基本可判定存在严重行链接。
查 v$segment_statistics 看实时链式访问趋势
行链接不是静态状态，而是运行时频繁触发的访问异常。只靠一次 analyze 容易漏判，必须看动态指标：
-
SELECT statistic_name, value FROM v$segment_statistics WHERE owner = 'YOUR_SCHEMA' AND object_name = 'YOUR_TABLE' AND statistic_name = 'chain row'—— 如果该值在业务高峰期每分钟涨几百甚至上千，说明应用正在高频访问被链接的行 - 对比同一表的
logical reads和physical reads：若chain row增长快于logical reads，说明每次逻辑读都在额外跳转，开销放大 - 注意：该视图默认不开启统计，需先执行
ALTER SYSTEM SET statistics_level = ALL（或至少TYPICAL），否则chain row始终为 0
用 analyze table ... validate structure cascade 定位具体行
这个命令是唯一能确认物理块内是否存在行链接/迁移的手段，但代价高、会锁表，务必在低峰执行：
- 先确保
chained_rows表存在：@?/rdbms/admin/utlchain.sql（路径以实际$ORACLE_HOME为准） - 执行：
ANALYZE TABLE your_table VALIDATE STRUCTURE CASCADE INTO chained_rows; - 查结果：
SELECT COUNT(*) FROM chained_rows WHERE table_name = 'YOUR_TABLE';—— 超过总行数的 1%（比如 100 万行中 >1 万条）即属严重 - 容易踩的坑：
VALIDATE STRUCTURE不检查 LOB 列，若表含CLOB/BLOB，需单独查dba_lobs的cache和logging属性，避免隐式缓存导致块溢出
别把 row migration 和 row chaining 混成一回事
两者现象相似（都导致单行跨块），但成因和修复方式完全不同，误判会导致白忙活：
-
row chaining：插入时一行就超块大小（如VARCHAR2(4000)+ 多列），Oracle 自动拆分——根本解法是调大db_block_size或拆分宽表 -
row migration：插入时正常，后续UPDATE扩容导致行搬走，原块留指针——修复只需ALTER TABLE your_table MOVE+ 重建索引，不需改块大小 - 快速区分：查
v$segment_statistics的table fetch continued row，该值高 +chain row高 → 倾向chaining；若table fetch by rowid明显高于table scan blocks gotten→ 更可能是migration
真正难的是判断“严重性”阈值——chained_rows 表里有 500 行，不一定影响性能；但若这 500 行恰好是订单主键查询最热的那批客户记录，就会卡住整个 OLTP 链路。所以必须把统计值和实际 SQL 的 buffer gets、current gets 关联起来看，而不是孤立盯一个数字。
