how to judge sql performance through these two explain?
EXPLAIN estimates row counts, often poorly.  Even so, the counts do not reflect how much stuff is hauled around.  If it is only id, that is not much.  If it is all of * (as in SELECT *), that is a lot more.  This is especially the case when it has to reach into the data to get all the columns.

Using index means that it is cruising through the index BTree.  Without that phrase, it is bouncing between the index BTree and the data BTree (using the PRIMARY KEY).  This bouncing is costly, and that cost is not adequately reflected in EXPLAIN.

Using index may be your only clue, but it cannot be trusted.  Sometimes it helps only a little, sometimes it helps a lot.

limit 700000,100 is an awful thing to do.  It must fetch 700100 rows (of just id or of *) but throw away nearly all of them.

Your complex query is the trick to make OFFSET perform somewhat better.  There is no way to say skip over 700000 rows without looking at them (which is what everyone wants).

Other notes:

Don't use CHAR, especially not with utf8; switch to VARCHAR.  char(120) consumes a fixed 360 bytes, regardless of the text.  The unnecessary bulk is a performance issue, especially if the table is bigger than can be cached.

More discussion of OFFSET.