学习笔记：Analyze MySQL Performance及慢日志的开启

Brought to you by Rick James

Analyze MySQL Performance

When asked to analyze the performance of a MySQL server, there are two main tasks (tuning and slowlog) I like to start with. The groundwork for them can be done by the customer. 
当被要求分析MySQL服务器的性能时，我想从两个主要任务（调优和慢速日志）开始。他们的基础工作可以由客户完成。

The deliverables:  可交付成果：

⚈  Short list of settings (VARIABLES) to change in my.cnf. 
    ⚈  Recommendations for speeding up the 'worst' queries. 
    ⚈  (possibly) Schema or Architectural recommendations.

⚈在my.cnf中更改的设置（VARIABLES）的简短列表。 
    ⚈加速“最差”查询的建议。 
    ⚈（可能）schema或架构建议。

In doing these tasks, I get a feel for what the system is doing, thereby jumpstarting any further involvement with the customer's site.

The tuning is usually a one-time task, but may be rerun as the data grows and/or major changes are made to the application.

The Slowlog analysis should be rerun periodically.

在完成这些任务时，我了解系统正在做什么，从而开始进一步参与客户的网站。

调整通常是一次性任务，但随着数据的增长和/或对应用程序进行重大更改，可能会重新运行。

应定期重新运行Slowlog分析。

Tuning

Please provide

⚈  How much RAM in the server 
    ⚈  SHOW VARIABLES; -- the tunables 
    ⚈  SHOW GLOBAL STATUS; -- various metrics

Please take GLOBAL STATUS after the server has been running at least 24 hours. (Otherwise things like 'cold cache' invalidate some of the findings.)

The SHOWs need to be in machine readable format.

Privacy: There is nothing very sensitive in the SHOWs. However, if you are especially paranoid, you could mask out any ip addresses and host names. Nothing significant will be lost from the analysis.

With those, I will use an automated script compute about 200 formulas and check for reasonable values. Usually about 20 are flagged as 'suspect'. Then I review them the results and clean up things. The bottom line is a few concrete recommendations for

⚈  Changing a few variables. 
    ⚈  (maybe) Converting away from MyISAM. (I have tips on the task, if you have not yet done such.) 
    ⚈  (maybe) Turn off the Query cache. (Perhaps under 5% of Production systems benefit from the QC.) 
    ⚈  (probably) Turning on and analyzing the slowlog (below).

If you choose to post online, see a free tool such as 
    ⚈  post.it 
    ⚈  pastebin 
Caveat: pastebin may get this (for reasons unknown): "This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff."

Slow queries and Slowlog

Setup:

⚈  Set long_query_time = 1 -- Preferrable in my.cnf We may change that threshhold up or down later, but this is a reasonable start. 
    ⚈  Set up the slowlog to be captured to FILE. 
    ⚈  Turn on (the details of this vary with the Version) 
    ⚈  Wait at least 24 hours.

Writing slow_log to file -- this is preferred, since there are tools for condensing such:

log_output = FILE
slow_query_log = ON
slow_query_log_file = (fullpath to some file)
long_query_time = 1
log_slow_admin_statements = ON
log_queries_not_using_indexes = OFF

Notes: 
    ⚈  log_output can be TABLE to write to mysql.slow_log, or FILE,TABLE to write both 
    ⚈  slow_query_log_file has a default; is not needed for TABLE 
    ⚈  long_query_time is a float, and can be as low as 0, but that gets verbose; default is a 'useless' 10 
    ⚈  admin statements tend to be slow but infrequent 
    ⚈  not_using_indexes is mostly clutter; simply worry about those that are slow 
    ⚈  If running on a Slave, consider using log_slow_slave_statements

Other options (version dependent; incomplete): 其他选项（依赖于版本;不完整）

log_slow_rate_limit=100
log_slow_rate_type=query
log_slow_verbosity=full
slow_query_log_always_write_time=1
slow_query_log_use_global_control=all
innodb_monitor_enable=all
userstat=1

Gather results for me (preferrably using FILE):

⚈  Digest the results using either of these:

`pt-query-digest` -- from Percona.com
`mysqldumpslow -s t`

⚈  Grab the first few (perhaps 5) queries. They will be sorted by (frequency * avg-time), which is the most useful. 
    ⚈  Provide SHOW CREATE TABLE -- for each table 
    ⚈  Provide EXPLAIN SELECT ... -- for each query

Analyze Results: Usually (not always), I can then provide a concrete suggestion on speeding up each query: 
分析结果：通常（并非总是），我可以提供加速每个查询的具体建议：

⚈  Add a particular index (often 'composite') 
    ⚈  Reformulate the query (a simple case is not hiding an indexed column in a function; more complex involves adding/removing subqueries) 
    ⚈  Recommend schema change 
    ⚈  Possibly even a architectural change (EAV is a common problem)

⚈添加特定索引（经常'复合'） 
    ⚈重新构造查询（一个简单的例子不是隐藏函数中的索引列;更复杂的涉及添加/删除子查询） 
    ⚈推荐架构更改 
    ⚈可能甚至是架构更改（EAV是常见问题）

Some common recommendations:

Many-to-Many mapping schema
Speeding up wp_postmeta
explode-implode problem of JOIN + GROUP BY
Pagination via OFFSET - instead "remember where you left off"

Posted June, 2017;   Slowlog: Sep, 2017