Some cases can also use this optimization, for example:

select v from t where id=1 and v>1 for update; -- Projection <- SelectLock <- Selection <- PointGet'
select * from t where id=1 union all select * from t where id=2; -- Union <- SelectLock <- PointGet
select * from t where id=1 union select * from t where id=1; -- HashAgg <- Union  <- SelectLock <- PointGet

I think BatchPointGet can also use this optimization, but the old code did not do it, any problem if we do it now?
@cfzjywxk

Seems it's ok as the locking behaviors are similar. Actually different behaviors for batch/point get have introduced us much trouble for us just like #32045.

BatchPointGet does not use txnManager.GetStmtForUpdateTS() in executorBuilder.getSnapshotTS(), which means it will not acquire ts from PD.

Try to avoid using any type but a concrete type in the interface definition, it would make it difficult to use and maintain.

It's hard to construct a concrete type here as the parameters of different advice type differs a lot. Could you give some suggestions?

It depends on the design of what's planned to be passed inside and how the parameters would be used. The most commonly used way is to abstract some interface or trait to describe the meaning of the input parameters, for example, you could abstract a new type named TxnAdvice which contains both advice type and value, or abstract a new interface which defines what should be passed in as the advice parameters.
The main thing is to answer what's an advice and how to describe it, what's the design?, but not just leave something like whatever type is acceptable, perhaps some will work some would not especially defining interfaces.

In general, don't use the any or inteface{} types it's not maintainable and other people have no idea what should be passed or how to build another advice type.

Where's the logic checking isBeiginStmt, the function name is a bit confusing.

Seems it's ok as the locking behaviors are similar. Actually different behaviors for batch/point get have introduced us much trouble for us just like #32045.