*: Support LOCK/UNLOCK TABLES feature (#10343)

[crazycs520]

What problem does this PR solve?

cherry-pick #10343

conflict file

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   config/config.go
        both modified:   config/config.toml.example
        both modified:   config/config_test.go
        both modified:   ddl/ddl_api.go
        both modified:   sessionctx/context.go

What problem does this PR solve?

Background

Currently, we only support LOCK TABLES/UNLOCK TABLES syntax, but actually do nothing.

TiDB only supports Optimistic Lock currently. A large write transaction maybe failed caused by other transaction has 1 insert. Large transaction retries are expensive， so we want to use LOCK TABLES to avoid this expensive retry.

Proposal

LOCK TABLES explicitly acquires table locks for the current client session. Table locks can be only acquired for base tables, not support for views. You must have the LOCK TABLES privilege, and the SELECT privilege for each table to be locked.

UNLOCK TABLES explicitly releases any table locks held by the current session.

LOCK TABLES implicitly releases any table locks held by the current session before acquiring new locks.

While the locks thus obtained are held, the session can access only the locked tables. Tables in the INFORMATION_SCHEMA database are an exception. They can be accessed without being locked explicitly.

tidb > LOCK TABLES t WRITE;
Query OK, 0 rows affected (0.00 sec)
tidb > SELECT COUNT(*) FROM t1;
ERROR 1100 (HY000): Table 't1' was not locked with LOCK TABLES
tidb > select * from INFORMATION_SCHEMA.VIEWS;
Empty set (0.00 sec)

LOCK TABLES or UNLOCK TABLES, when applied to a partitioned table, always locks or unlocks the entire table; these statements do not support partition lock pruning.

Principles

1. If a session issues a LOCK TABLES statement to acquire a lock while already holding locks, its existing locks are released implicitly before the new locks are granted.
2. If a session begins a transaction (for example, with START TRANSACTION), an implicit UNLOCK TABLES is performed, which causes existing locks to be released. (not implement currently)

The Difference with Mysql LOCK TABLE

1. You can't implement transaction with LOCK TABLES and UNLOCK TABLES in TiDB. If you need transaction, you should also execute begin after LOCK TABLES.

   Table locks of mysql is metadata locks, and user can use table locks to implement transaction when the mysql storage engine is nontransactional.

   Because MySQL execute select/insert/update will automatically to acquire the related table locks first. If session 1 is executing a select * from t1, and session 2 execute lock tables t1 write, then session 2 won't aquire the t1 table lock untill the session 1 execute finish. Details as follows chart:

Time	Session 1( In MySQL)	Session 2 ( In MySQL)
t1	Select * from t1
t2	Acquire t1 table lock.
t3	doing	Lock tables t1 write
t4	doing	waiting
t5	(Select * from t1) Finish	waiting
t6	Release t1 table lock.	waiting
t7		(Lock tables t1 write ) sucess.

But in TiDB, session2 will aquire the t1 table lock soon. Because session 1 won't acquire the t1 table lock. In TiDB, It is very expensive to acquire the related table locks when execute DML like select/insert. Details in TiDB as follows chart:

Time	Session 1( In TiDB)	Session 2 ( In TiDB)
t1	Select * from t1
t2	doing	Lock tables t1 write
t3	doing	(Lock tables t1 write ) sucess.
t4	(Select * from t1) Finish

2. MySQL session1 execute LOCK TABLES t1 write, if other session2 obtains the lock of t1, session 1 will wait until the session2 release t1 lock. In TiDB, session 1 will return error like: Table 't1' was locked by server xx session xx.

   Time	Session 1	session 2 In MySQL	Session 2 in TiDB
   t1	Lock tables t1 read
   t2		Lock tables t1 write	Lock tables t1 write
   t3		wait	Error: Table 't1' was locked by server xx session 1
   t4	Unlock tables.	wait
   t5		Lock tables t1 write sucess.

3. TiDB table lock not support alias name currently. TiDB will lock the table.ID instead of table.Name

What is changed and how it works?

1. Store TableLockInfo in TableInfo.
2. Use DDL to implement LOCK TABLES and UNLOCK TABLES. So add 2 DDL job type: ActionLockTable, ActionUnlockTable.
3. Store lockedTables map in session. lockedTables use to record the table locks hold by the session.
4. Check the table locked before execute. CheckTableLock will use the visitInfo to check table locked. This check was add after the CheckPrivilege.

Related parser PR: pingcap/parser#305

Check List

Tests

• Unit test
• Integration test( need more test, in doing )

Code changes

• Has exported function/method change

Side effects

• Possible performance regression

Release note

[crazycs520]

/run-all-tests

[crazycs520]

/rebuild

[crazycs520]

/build

[crazycs520]

Ci will happy after the parser PR merged, pingcap/parser#827 @bb7133 PTAL

[zimulala]

LGTM

[crazycs520]

/run-all-tests

[crazycs520]

/rebuild

[crazycs520]

/rebuild

[bb7133]

LGTM

[bb7133]

/merge

[sre-bot]

/run-all-tests