Table of Contents

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. 

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