Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

sql: update slow query document #663

Merged
merged 4 commits into from
Oct 12, 2018
Merged

sql: update slow query document #663

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5dc7777
sql: update slow query document
tiancaiamao Oct 11, 2018
3ac7f9d
address comment
tiancaiamao Oct 11, 2018
a9e41ef
address comment
tiancaiamao Oct 12, 2018
7113099
address comment
tiancaiamao Oct 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions sql/slow-query.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,3 +95,25 @@ The SQL statement.
Not all of the `SLOW_QUERY` statements are problematic. Only those whose `process_time` is very large will increase the pressure on the entire cluster.

The statements whose `wait_time` is very large and `process_time` is very small are usually not problematic. The large `wait_time` is because the statement is blocked by real problematic statements and it has to wait in the execution queue, which leads to a much longer response time.

### `admin show slow` command

Besides obtaining the TiDB log file, another way to identify the slow query is through the `admin show slow` SQL command:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May I suggest: "In addition to the TIDB log file, you can identify slow queries by running the admin show slow."

besides could implies it is an either/or, but there is a use case for both.


admin show slow recent N
admin show slow top [internal | all] N
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For code blocks and the following part, please refer to my comments here: pingcap/docs-cn#922


`recent N` shows the recent N slow query records, for example:

admin show recent 10

`top N` shows the slowest N query records recently (within a few days).
If the `internal` option is provided, the returned results would be the inner SQL executed by the system;
If the `all` option is provided, the returned results would be the user's SQL combinated with inner SQL;
Otherwise, this command would only return the slow query records from the user's SQL.

admin show top 3
admin show top internal 3
admin show top all 5

Due to the memory footprint restriction, the stored slow query records count is limited. If the specified `N` is greater than the records count, the returned records count may be smaller than `N`.