Reorder the columns of the deadlocks table

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

docs/design/2021-04-26-lock-view.md

@@ -85,12 +85,12 @@ Several tables will be provided in `information_schema`. Some tables has both lo
 |------------|------------|---------|
 | `DEADLOCK_ID` | `int` | There needs multiple rows to represent information of a single deadlock event. This field is used to distinguish different events. |
 | `OCCUR_TIME` | `time` | The physical time when the deadlock occurs |
+| `RETRYABLE` | `bool` | Is the deadlock retryable. TiDB tries to determine if the current statement is (indirectly) waiting for a lock locked by the current statement. |
 | `TRY_LOCK_TRX_ID` | `unsigned bigint` | The transaction ID (start ts) of the transaction that's trying to acquire the lock |
 | `CURRENT_SQL_DIGEST` | `text` | The SQL that's being blocked |
 | `KEY` | `varchar` | The key that's being locked, but locked by another transaction in the deadlock event |
 | `ALL_SQLS` | `text` | A list of the digest of SQL statements that the transaction has executed |
 | `TRX_HOLDING_LOCK` | `unsigned bigint` | The transaction that's currently holding the lock. There will be another record in the table with the same `DEADLOCK_ID` for that transaction. |
-| `RETRYABLE` | `bool` | Is the deadlock retryable. TiDB tries to determine if the current statement is (indirectly) waiting for a lock locked by the current statement. |
 
 * Life span of rows:
  * Create after TiDB receive a deadlock error