怎么解析與優化MySQL 8.0 PFS histogram

這篇文章主要介紹“怎么解析與優化MySQL 8.0 PFS histogram”，在日常操作中，相信很多人在怎么解析與優化MySQL 8.0 PFS histogram問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么解析與優化MySQL 8.0 PFS histogram”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

線上數據庫的運維，往往避不開對語句執行時間的監控，實際業務運行中若出現明顯、頻繁的慢查詢或慢寫入，則我們需要格外地注意，及時定位問題出現的原因。

這時候，如果數據庫自身能夠提供實例上語句執行時間的統計，做到可宏觀（能夠觀察整體執行時間分布情況）、可微觀（能夠定位執行慢的語句），自然能起到事半功倍的效用。

早在MySQL 8.0以前的版本中，performance_schema表就已經有多個Statement Summary表，用于記錄當前或近期的語句執行事件。

mysql> show tables from performance_schema like 'events_statements_summary%';+-----------------------------------------------------------+| Tables_in_performance_schema (events_statements_summary%) |+-----------------------------------------------------------+| events_statements_summary_by_account_by_event_name        || events_statements_summary_by_digest                       || events_statements_summary_by_host_by_event_name           || events_statements_summary_by_program                      || events_statements_summary_by_thread_by_event_name         || events_statements_summary_by_user_by_event_name           || events_statements_summary_global_by_event_name            |+-----------------------------------------------------------+7 rows in set (0.00 sec)

按照對事件的grouping策略的不同，這些語句事件summary表一共劃分成了7個。其中events_statements_summary_by_digest按照語句的digest值和語句所操作的schema名這兩個元素來分組存儲數據，表中的每一行數據總結了一個schema上執行的一組相同性質（具體值可以不同）的語句的執行信息。

其中，語句的digest指的是一個語句去掉語句內某些具體的值（如插入表中的具體值）、進行模板化之后的語句，再經過哈希算法得到的唯一值。例如，某個語句INSERT INTO d1.t1 VALUES(1024, "hello world")先經過模板化，得到模板語句INSERT INTO d1.t1 VALUES(...)，然后經過哈希得到一個唯一的digest值。

舉個例子，我向test庫中的texts表插入了四行數據：

mysql> use test;Database changedmysql> insert into texts values("hello");Query OK, 1 row affected (0.00 sec)mysql> insert into texts values("hi");Query OK, 1 row affected (0.01 sec)mysql> insert into texts values("how are you");Query OK, 1 row affected (0.01 sec)mysql> insert into texts values("goodbye");Query OK, 1 row affected (0.01 sec)

然后可以在表中找到上面四條INSERT執行的統計數據：

mysql> select * from performance_schema.events_statements_summary_by_digest where schema_name='test'\G...*************************** 4. row ***************************                SCHEMA_NAME: test                     DIGEST: 894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b                DIGEST_TEXT: INSERT INTO `texts` VALUES (?)    # 模板化后的語句                 COUNT_STAR: 4            # 屬于該digest的實際語句執行數量             SUM_TIMER_WAIT: 29030259000  # 語句執行時間總和             MIN_TIMER_WAIT: 6432990000   # 語句執行時間最小值             AVG_TIMER_WAIT: 7257564000   # 語句執行時間平均值             MAX_TIMER_WAIT: 8168797000   # 語句執行時間最大值              SUM_LOCK_TIME: 495000000                 SUM_ERRORS: 0               SUM_WARNINGS: 0          SUM_ROWS_AFFECTED: 4              SUM_ROWS_SENT: 0          SUM_ROWS_EXAMINED: 0SUM_CREATED_TMP_DISK_TABLES: 0     SUM_CREATED_TMP_TABLES: 0       SUM_SELECT_FULL_JOIN: 0 SUM_SELECT_FULL_RANGE_JOIN: 0           SUM_SELECT_RANGE: 0     SUM_SELECT_RANGE_CHECK: 0            SUM_SELECT_SCAN: 0      SUM_SORT_MERGE_PASSES: 0             SUM_SORT_RANGE: 0              SUM_SORT_ROWS: 0              SUM_SORT_SCAN: 0          SUM_NO_INDEX_USED: 0     SUM_NO_GOOD_INDEX_USED: 0                 FIRST_SEEN: 2020-07-09 16:08:33.329338 # 屬于該digest的已執行語句中，第一條執行的時刻                  LAST_SEEN: 2020-07-09 16:08:47.193867 # 屬于該digest的已執行語句中，最后一條執行的時刻                QUANTILE_95: 8317637711   # 95%的同digest語句執行時間小于這個值                QUANTILE_99: 8317637711   # 99%的同digest語句執行時間小于這個值               QUANTILE_999: 8317637711   # 99.9%的同digest語句執行時間小于這個值          QUERY_SAMPLE_TEXT: insert into texts values("hi")    # 屬于該digest的已執行語句中的某個樣本          QUERY_SAMPLE_SEEN: 2020-07-09 16:08:37.642837        # 樣本執行的時刻    QUERY_SAMPLE_TIMER_WAIT: 8168797000                        # 樣本執行耗時4 rows in set (0.00 sec)

這里COUNT_STAR列指出了執行的同一digest的語句有4個，與我上面的實際插入操作相符。緊跟其后的是幾個我們比較關注的統計數據，SUM_TIMER_WAIT代表這4條插入執行的總耗時是29030259000 ps，也就是大約29.03 ms；MIN_TIMER_WAIT代表這4條插入中耗時最短的一條花了6.43 ms；AVG_TIMER_WAIT代表這4條插入中平均耗時7.25 ms；MAX_TIMER_WAIT代表這4條插入中耗時最長的一條花了8.16 ms。

三個QUANTILE_xx字段也是我們比較關注的數據之一。上例中QUANTILE_95值為8317637711，表示95%的同digest語句執行耗時在8.31 ms以內；

以此類推，下面的QUANTILE_99和QUANTILE_999分別表示99%和99.9%。

這里需要注意，最后三列是MySQL 8.0給該表新增的三個字段，其給出了上面執行的4條插入中的一個樣本（sample），并提供了這個樣本的（最后一次）執行時間與耗時兩個信息。

上面提到的summary表中，比較籠統的記錄了語句執行的耗時等信息，包含了最大值、最小值、平均值等，但是這些信息可能不夠，不能直觀地看到同一語句的用時分布情況。

在MySQL 8.0中，performance_schema中新增了兩個histogram表使得語句執行時間的統計信息更加豐富，分別是events_statements_histogram_by_diges和events_statements_histogram_global

Histogram的中文意指“直方圖”，顧名思義，這兩個表所提供的是對語句執行事件執行時間的直方圖形式的統計記錄。

2.1 events_statements_histogram_by_digest介紹

mysql> select * from performance_schema.events_statements_histogram_by_digest     -> where DIGEST='894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b'    -> and SCHEMA_NAME='test' and COUNT_BUCKET>0\G*************************** 1. row ***************************           SCHEMA_NAME: test                DIGEST: 894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b         BUCKET_NUMBER: 141      BUCKET_TIMER_LOW: 6309573444     BUCKET_TIMER_HIGH: 6606934480          COUNT_BUCKET: 1COUNT_BUCKET_AND_LOWER: 1       BUCKET_QUANTILE: 0.250000*************************** 2. row ***************************           SCHEMA_NAME: test                DIGEST: 894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b         BUCKET_NUMBER: 143      BUCKET_TIMER_LOW: 6918309709     BUCKET_TIMER_HIGH: 7244359600          COUNT_BUCKET: 1COUNT_BUCKET_AND_LOWER: 2       BUCKET_QUANTILE: 0.500000*************************** 3. row ***************************           SCHEMA_NAME: test                DIGEST: 894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b         BUCKET_NUMBER: 144      BUCKET_TIMER_LOW: 7244359600     BUCKET_TIMER_HIGH: 7585775750          COUNT_BUCKET: 1COUNT_BUCKET_AND_LOWER: 3       BUCKET_QUANTILE: 0.750000*************************** 4. row ***************************           SCHEMA_NAME: test                DIGEST: 894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b         BUCKET_NUMBER: 146      BUCKET_TIMER_LOW: 7943282347     BUCKET_TIMER_HIGH: 8317637711          COUNT_BUCKET: 1COUNT_BUCKET_AND_LOWER: 4       BUCKET_QUANTILE: 1.0000004 rows in set (0.00 sec)

在events_statements_histogram_by_digest中，同一digest值的語句事件按照執行時間大小被納入不同的bucket中，BUCKET_TIMER_LOW字段表示該bucket內語句事件的執行時間下限，BUCKET_TIMER_HIGH字段表示上限，如上面我所執行的4條插入，其中一條的執行時間在6309573444 ps = 6.30 ms到6606934480 ps = 6.60 ms之間，因此該語句事件被收入BUCKET_NUMBER（bucket的標識數字）為141的bucket中。

COUNT_BUCKET字段的數值表示有多少語句事件被收入該bucket中，在本例中，4條插入的執行時間差距比較大，因此被收入了4個不同的bucket中，并且我在查詢的時候指定了篩選出COUNT_BUCKET大于0的結果，因此所以“空bucket”的數據都沒有展示。COUNT_BUCKET_AND_LOWER表示有多少語句事件的執行時間比該bucket的上限小，BUCKET_QUANTILE則表示有百分之多少的語句事件的執行時間比該bucket的上限小，在本例中，第144個bucket（在第3行）的執行時間上限是7.58 ms，有4條插入中有3條的執行時間小于這個值，也就是75%的執行時間小于這個值。

mysql> SELECT DIGEST_TEXT,    -> CONCAT('<',ROUND(BUCKET_TIMER_HIGH/1000000000,2),'ms') as 'TIME',    -> CONCAT(RPAD('',ROUND(BUCKET_QUANTILE*100/4),'*'),ROUND(BUCKET_QUANTILE*100,2),"%") QUANTILE    -> FROM events_statements_histogram_by_digest t1    -> JOIN events_statements_summary_by_digest t2    -> ON t2.DIGEST = t1.DIGEST    -> WHERE COUNT_BUCKET >0 and t1.DIGEST='894869beecac725bf46aa9c43778d476252a5b1c85ecd0139287ab15b2bd3c0b'    -> ORDER BY t1.DIGEST, BUCKET_TIMER_HIGH DESC;+--------------------------------+---------+----------------------------------+| DIGEST_TEXT                    | TIME    | QUANTILE                         |+--------------------------------+---------+----------------------------------+| INSERT INTO `texts` VALUES (?) | <8.32ms | *************************100.00% || INSERT INTO `texts` VALUES (?) | <7.59ms | *******************75.00%        || INSERT INTO `texts` VALUES (?) | <7.24ms | ************50.00%               || INSERT INTO `texts` VALUES (?) | <6.61ms | ******25.00%                     |+--------------------------------+---------+----------------------------------+4 rows in set (0.00 sec)

2.2 events_statements_histogram_global介紹

在events_statements_histogram_global表中，不再按照schema名或語句事件的digest來標識行，而是把所有的語句事件不做任何區分，直接扔入代表不同執行時間區間的bucket中，因此得到的將是對語句事件執行時間的一個宏觀的統計數據：

mysql> show create table performance_schema.events_statements_histogram_global\G*************************** 1. row ***************************       Table: events_statements_histogram_globalCreate Table: CREATE TABLE `events_statements_histogram_global` (  `BUCKET_NUMBER` int(10) unsigned NOT NULL,  `BUCKET_TIMER_LOW` bigint(20) unsigned NOT NULL,  `BUCKET_TIMER_HIGH` bigint(20) unsigned NOT NULL,  `COUNT_BUCKET` bigint(20) unsigned NOT NULL,  `COUNT_BUCKET_AND_LOWER` bigint(20) unsigned NOT NULL,  `BUCKET_QUANTILE` double(7,6) NOT NULL,  PRIMARY KEY (`BUCKET_NUMBER`)) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)

在Percona 5.7中，有個QUERY_RESPONSE_TIME插件，用一個query_response_time表來統計所有語句的執行時間，得到執行時間的分布情況：

mysql> select * from information_schema.query_response_time where COUNT>0;+----------------+-------+----------------+| TIME           | COUNT | TOTAL          |+----------------+-------+----------------+|       0.000015 |     6 |       0.000052 ||       0.000061 |     8 |       0.000367 ||       0.000122 |    20 |       0.001775 ||       0.000244 |     8 |       0.001438 ||       0.000488 |     8 |       0.002514 ||       0.000976 |     4 |       0.002079 ||       0.001953 |     4 |       0.004707 ||       0.003906 |     1 |       0.002767 ||       0.007812 |     3 |       0.020409 ||       0.015625 |     6 |       0.066448 ||       0.031250 |     3 |       0.057138 ||       0.062500 |     2 |       0.097577 ||       0.125000 |     1 |       0.079703 ||       8.000000 |     1 |       5.000150 |+----------------+-------+----------------+14 rows in set (0.00 sec)

mysql> select CONCAT(BUCKET_TIMER_HIGH/1000000000, " ms") TIME, COUNT_BUCKET COUNT    -> from performance_schema.events_statements_histogram_global where COUNT_BUCKET>0;+------------+-------+| TIME       | COUNT |+------------+-------+|0.0437 ms  |     1 || 0.0631 ms  |     1 ||0.0692 ms  |     2 || 0.1202 ms  |     2 ||0.1318 ms  |     2 || 0.1445 ms  |     2 ||0.1738 ms  |     1 || 0.2399 ms  |     1 ||0.3020 ms  |     1 || 0.4786 ms  |     1 ||0.5012 ms  |     2 || 0.5248 ms  |     7 ||0.5495 ms  |     8 || 0.5754 ms  |     6 ||0.6026 ms  |     5 || 0.6310 ms  |     9 ||0.6607 ms  |     4 || 0.6918 ms  |     9 ||0.7244 ms  |     4 || 0.7586 ms  |     3 ||0.7943 ms  |     7 || 0.8318 ms  |     3 ||0.8710 ms  |     2 || 0.9120 ms  |     1 ||0.9550 ms  |     4 || 1.0000 ms  |     3 ||1.0471 ms  |     2 || 1.0965 ms  |     1 ||1.1482 ms  |     2 || 1.2023 ms  |     6 ||1.2589 ms  |     6 || 1.3183 ms  |     2 ||1.4454 ms  |     1 || 1.5136 ms  |     1 ||1.6596 ms  |     3 || 1.7378 ms  |     3 ||2.1878 ms  |     1 || 2.2909 ms  |     1 ||2.6303 ms  |     2 || 3.0200 ms  |     1 ||3.1623 ms  |     1 || 5.7544 ms  |     1 ||6.6069 ms  |     1 || 7.2444 ms  |     1 ||7.5858 ms  |     1 || 8.3176 ms  |     1 ||10.9648 ms |     1 || 41.6869 ms |     1 |+------------+-------+48 rows in set (0.00 sec)

由于MySQL 8.0所提供的histogram表既可以宏觀統計語句執行時間，又可以具體定位某個語句的執行時間分布，功能上已經比Percona的QUERY_RESPONSE_TIME插件更加豐富，因此在Percona 8.0中這一插件也被移除。

3.1 原生MySQL的局限

mysql> select count(*) from performance_schema.events_statements_histogram_global;+----------+| count(*) |+----------+|      450 |+----------+1 row in set (0.00 sec)

在events_statements_histogram_by_digest中，每條digest所對應的histogram的bucket數量也是450，則mysqld記錄了n條digest，events_statements_histogram_by_digest表中就有n * 450行數據：

mysql> select count(*) from performance_schema.events_statements_histogram_by_digest;+----------+| count(*) |+----------+|     8100 |+----------+1 row in set (0.00 sec)# 注：此時服務器記錄有18條digest記錄

接著我通過SHOW VARIABLES查找是否存在某個變量可以調整bucket的數量，沒有找到相關的結果，進一步查看源碼，發現這一部分是用一個宏定義硬編碼了bucket的數量：

/**
  @file storage/perfschema/pfs_histogram.h
*/

/** Number of buckets used in histograms. */
#define NUMBER_OF_BUCKETS 450

并且針對每個bucket所代表的時間區間，硬編碼了一個最小時間上限和bucket增長指數：

/**
  @file storage/perfschema/pfs_histogram.cc
*/

/**
  Histogram base bucket timer, in picoseconds.
  Currently defined as 10 micro second.
  
  @解釋：最小的bucket（第1個bucket）的時間上限，值為10ms。
*/
#define BUCKET_BASE_TIMER (10 * 1000 * 1000)

/**
  Bucket factor.
  histogram_timer[i+1] = BUCKET_BASE_FACTOR * histogram_timer[i]
  The value is chosen so that BUCKET_BASE_FACTOR ^ 50 = 10,
  which corresponds to a 4.7 percent increase for each bucket,
  or a power of 10 increase for 50 buckets.

  @解釋：每個bucket相比前一個bucket的時間上限增長指數。
  例，
  第1個bucket的時間上限是10ms，則對于第2個bucket：
  時間上限是10*1.0471285480508996ms，約為10.47ms；時間下限則是前一個bucket的上限值，也就是10ms。
*/
#define BUCKET_BASE_FACTOR 1.0471285480508996

這一部分硬編碼存在如下問題：

不同的業務的讀寫需求不一致，所需要的執行時間監測粒度也盡不相同。MySQL默認強制劃分成450個bucket，bucket的增長指數是1.047，雖然劃分得非常精細，但是可能實際業務并不需要這么精細的監測粒度，也許我們只需要幾十個bucket，并且將10ms的執行時間與20ms的執行時間一視同仁，算進一個bucket里。因此如果bucket的數量與bucket的增長指數可以視作變量人為調整，可以使得histogram的統計更加符合實際業務的需求。

就如在前面所提到的，events_statements_histogram_by_digest表中的行數是digest記錄的數量與450的乘積，不管實際的語句事件執行時間有沒有落到某個bucket里，也就是說即便某個bucket的count值是空的，其也在表中占據一行。假如某一digest語句事件執行時間的分布比較均勻，使得空bucket比較少，那倒沒什么，但是實際情況通常是某一digest的語句事件的執行時間集中分布在某個小范圍內，可能最多占幾十個bucket，剩下幾百個bucket可能一直不會用到，使得絕大部分的行是浪費的，我們知道performance_schema中的表都是內存表，數據存放在內存中，這也就直接導致服務器的內存被浪費。

為了驗證第二個問題，我進一步查看源碼。首先在pfs_digest.h中，定義了PFS_statements_digest_stat類，解讀源碼可以發現一個該類的對象對應events_statements_summary_by_digest表（注意是summary表）中的一條記錄，包含了我們前面所見到的digest值、sample與第一次和最后一次執行時刻等信息（在下面代碼中忽略）。在里面我們可以看到一個PFS_histogram對象的成員，這里猜測其應當是一條digest記錄所對應的histogram。

/** A statement digest stat record. */struct PFS_ALIGNED PFS_statements_digest_stat {  /* 其他成員變量與成員函數在此省略 */  // FIXME : allocate in separate buffer  PFS_histogram m_histogram; /* 一個digest所對應的histogram */};

接著查看PFS_histogram類的定義，其唯一的成員是一個長度為宏定義NUMBER_OF_BUCKETS（值為450）的數組，不難看出這個成員就是histogram中bucket的計數數組。假設某個digest值的語句執行時間為10.1 ms，這一時間對應的bucket應當是第2個bucket，那么該digest的histogram中對應的bucket計數應該加1，也就是m_bucket[1]++，實際代碼中通過調用increment_bucket公共接口進行計數累加。

struct PFS_histogram { public:  void reset();  void increment_bucket(uint bucket_index) { m_bucket[bucket_index]++; }  ulonglong read_bucket(uint bucket_index) { return m_bucket[bucket_index]; } private:  std::atomic<ulonglong> m_bucket[NUMBER_OF_BUCKETS];};

上面的代碼可以看到，1條digest記錄包含了1個屬于該digest的histogram，這個histogram中有一個長度為450的無符號長整數數組作bucket計數用途。那么所有digest記錄是怎么實際存儲在內存中的呢？我們接著查看源碼，可以在pfs_digest.cc中找到一個PFS_statements_digest_stat對象的動態數組，用于存放所有的digest記錄：

/** EVENTS_STATEMENTS_SUMMARY_BY_DIGEST buffer. */PFS_statements_digest_stat *statements_digest_stat_array = NULL;

這個動態數組的實際內存分配代碼如下：

statements_digest_stat_array = PFS_MALLOC_ARRAY(    &builtin_memory_digest, digest_max, sizeof(PFS_statements_digest_stat),    PFS_statements_digest_stat, MYF(MY_ZEROFILL));/*   @注：以上代碼近似于   statements_digest_stat_array = malloc(digest_max * sizeof(PFS_statements_digest_stat));*/

可以看到PFS_statements_digest_stat的長度由變量digest_max決定，其代表服務器允許的最大digest記錄數量，也就是events_statements_summary_by_digest表的最大行數，而digest_max的值由global變量performance_schema_digests_size決定，其默認值為10000，最大允許值為1024 * 1024。

mysql> show variables like 'performance_schema_digests_size';+---------------------------------+-------+| Variable_name                   | Value |+---------------------------------+-------+| performance_schema_digests_size | 10000 |+---------------------------------+-------+1 row in set (0.00 sec)

結合以上源碼我們可以得出結論，假設各個histogram中的450個bucket最多只有32個是實際需要用到的，在performance_schema_digests_size取默認值10000的情況下，由于所有digest記錄的內存是預先分配好的，會造成10000 * (450 - 32) * sizeof(ulonglong) = 31.89 MB的內存浪費；而在performance_schema_digests_size取最大允許值時，更是會造成1024 * 1024 * (450 - 32) * sizeof(ulonglong) = 3344 MB的內存浪費。

3.2 所作改進

針對這兩個問題，我分成兩步進行改進。

首先在第一步，我們引入兩個只讀global的變量performance_schema_events_statements_histogram_bucket_number和performance_schema_events_statements_histogram_base_factor，分別用作histogram中bucket的數量（默認值為32）與每個bucket時間上限的增長指數（默認值為2.0），取代原生版本中的硬編碼：

mysql> show variables like 'performance_schema_events_statements_histogram%';+--------------------------------------------------------------+----------+| Variable_name                                                | Value    |+--------------------------------------------------------------+----------+| performance_schema_events_statements_histogram_base_factor   | 2.000000 || performance_schema_events_statements_histogram_bucket_number | 32       |+--------------------------------------------------------------+----------+2 rows in set (0.00 sec)

用戶若需要采用不同的bucket數量與增長指數，只需在啟動mysqld時指定變量值即可：

$ mysqld --performance_schema_events_statements_histogram_bucket_number=64 --performance_schema_events_statements_histogram_base_factor=1.5

經過這個改進，用戶可以靈活地調整histogram的統計粒度，使之更符合運維管理的特定化需求。采用默認值的實際效果如下：

mysql> insert into testTable values('first');Query OK, 1 row affected (0.00 sec)mysql> insert into testTable values('second');Query OK, 1 row affected (0.01 sec)mysql> insert into testTable values('third');Query OK, 1 row affected (0.01 sec)mysql> insert into testTable values('fourth');Query OK, 1 row affected (0.01 sec)mysql> insert into testTable values('fifth');Query OK, 1 row affected (0.02 sec)mysql> select DIGEST, DIGEST_TEXT from performance_schema.events_statements_summary_by_digest where DIGEST_TEXT like 'INSERT%';+------------------------------------------------------------------+------------------------------------+| DIGEST                                                           | DIGEST_TEXT                        |+------------------------------------------------------------------+------------------------------------+| 9cb9e9a5b12f41fb4e28ca6c2ed37843a47222a8903dc4f6b6ceb35bb8445012 | INSERT INTO `testTable` VALUES (?) |+------------------------------------------------------------------+------------------------------------+1 row in set (0.00 sec)mysql> select * from performance_schema.events_statements_histogram_by_digest where DIGEST='9cb9e9a5b12f41fb4e28ca6c2ed37843a47222a8903dc4f6b6ceb35bb8445012'\G...*************************** 11. row ***************************           SCHEMA_NAME: testdb                DIGEST: 9cb9e9a5b12f41fb4e28ca6c2ed37843a47222a8903dc4f6b6ceb35bb8445012         BUCKET_NUMBER: 10      BUCKET_TIMER_LOW: 5120000000     BUCKET_TIMER_HIGH: 10240000000          COUNT_BUCKET: 3COUNT_BUCKET_AND_LOWER: 3       BUCKET_QUANTILE: 0.600000*************************** 12. row ***************************           SCHEMA_NAME: testdb                DIGEST: 9cb9e9a5b12f41fb4e28ca6c2ed37843a47222a8903dc4f6b6ceb35bb8445012         BUCKET_NUMBER: 11      BUCKET_TIMER_LOW: 10240000000     BUCKET_TIMER_HIGH: 20480000000          COUNT_BUCKET: 2COUNT_BUCKET_AND_LOWER: 5       BUCKET_QUANTILE: 1.000000...32 rows in set (0.00 sec)

到此，關于“怎么解析與優化MySQL 8.0 PFS histogram”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！