当我们插入一条数据时，首先这个动作会被记录到redo log 中，操作也会被记录到到undo ，undo本身的动作也会做为一条数据被记录到redo log ，插入一条数据，索引（indexes）会发生变化，索引的变化也会做一条数据被记录到redo log

索引维护也会产生相应的重做日志的
这样才能保证在应用日志恢复的时候相应的索引也会被更改

当然会。

记住一个本质原则，对于涉及到块更改操作均会记录redo信息。

你想想延迟块清除，只是数据库中的事务槽的更改都会记录redo（某些情况下select会导致redo产生的本质原因）更不要说是维护索引的相对“重量级”操作。

自己又想了想，个人认为随着表的增删改而自动更新索引的操作不会记录redo，undo。(不考虑人工增加，删除、rebuild、修改索引这种DDL情况。)
因为：索引的更新是自动根据表的增删改而发生，如果索引或索引相关变更信息也记录redo和undo，那么在做回滚和前滚的时候，索引自动维护机制和前滚（回滚）中登记的索引变化更新会发生冲突。

我觉得会的。说下我的理解：在oracle里，索引和数据分属不同的segment，底层都是block，删除一条数据就要维护索引树，都需要对block进行操作，为了实现崩溃恢复，必然需要把这些变动都写入redo log，而且我猜，跟数据块的redo一并写入的，如果分属两个原子操作，那又要保证这两个操作的事务性。

自己简单测试一下，一目了然，为啥要猜，凭感觉？

SQL> create table t1 (id number);

Table created.

SQL> insert all
  2  into t1 values(1)
  3  into t1 values(2)
  4  into t1 values(3)
  5  select 1 from dual;

3 rows created.

SQL> commit;

Commit complete.

SQL> create index idx_t1 on t1(id);

Index created.

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
   46939397

SQL> update t1 set id=5 where id=3;

1 row updated.

SQL> commit;

Commit complete.

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
   46939443

SQL> alter system dump logfile '/u01/app/oracle/oradata/HKORA/onlinelog/o1_mf_3_j7z2qcb9_.log' scn min 46939397 scn max 46939443;

System altered.

SQL> @tracefile

VALUE
------------------------------------------------------------------------------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/hkora/hkora/trace/hkora_ora_15168.trc

SQL> select object_id from dba_Objects where object_Name='T1' and owner='DEVIN';

 OBJECT_ID
----------
     82502

SQL> select object_id from dba_Objects where object_Name='IDX_T1';

 OBJECT_ID
----------
     82503

CHANGE #3 CON_ID:0 TYP:2 CLS:1 AFN:8 DBA:0x0200240c OBJ:82502 SCN:0x0000000002cc3cbe SEQ:1 OP:11.5 ENC:0 RBL:0 FLG:0x0000

CHANGE #2 CON_ID:0 TYP:0 CLS:1 AFN:8 DBA:0x02002413 OBJ:82503 SCN:0x0000000002cc3cd7 SEQ:1 OP:10.4 ENC:0 RBL:0 FLG:0x0000