Digester produces invalid sql for selecting global variables

[wjhuang2016]

Bug Report

1. Minimal reproduce step (Required)

Linked issue.

The digester produces an invalid SQL for the following statement:

SELECT @@global.tidb_stmt_summary_refresh_interval AS value

This statement is generated by the tidb-dashboard.

I have another digester bug in pingcap/tidb#14241 - it is annoying when the syntax generated back is invalid.

2. What did you expect to see? (Required)

SELECT @@global.tidb_stmt_summary_refresh_interval AS value

3. What did you see instead (Required)

There is a space between the two @ symbols:

SELECT @ @global.tidb_stmt_summary_refresh_interval AS value

4. Affected version (Required)

mysql> select tidb_version()\G
*************************** 1. row ***************************
tidb_version(): Release Version: v4.0.0-beta.2-684-gf590d74e1
Edition: Community
Git Commit Hash: f590d74e158cf4e33555bfeb8f88971af5956697
Git Branch: master
UTC Build Time: 2020-06-27 02:29:48
GoVersion: go1.13.8
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
1 row in set (0.00 sec)

5. Root Cause Analysis

[baurine]

I suggest to fix this issue in 2 steps:

1. Copy original content instead of formatted content when clicking the "Copy" button
2. Fix the incorrect format behavior for sql-formatter-plus-plus lib

For step 1, some reasons (personal opinion):

1. It seems most people report the formatted SQL is incorrect because they copy and paste to run it in the SQL client, found it doesn't work, else they can't notice the incorrectness. So I think people (especially the DBAs) care the correctness more than style.
2. Formatting the SQL belongs view layer staff, it is just for easy reading, but when copying and pasting to SQL client, the style is not that important.
3. We can't confirm the sql-formatter-plus-plus lib won't format some others incorrectly, we need to fix them case by case.
4. Copying the formatted content makes locate the problem more complex a bit. If people report the formatted SQL doesn't work, we need to find out whether it happened in the TiDB layer or dashboard layer.

hi @breeswish , how do you think about it?

[breezewish]

According to my OnCall experience formatting SQL is very frequently used, even for copied content, since an unformatted SQL is usually not readable, for example, too long, or all in one line, which makes people hard to know what is it and what's inside (is it a join? does it contain sub queries? etc) .

How about introducing "Copy Original" and "Copy Formatted"? This may be good for all cases.

[baurine]

Ok, we can do that.