本文介紹了分析和解決慢SQL的方法。
從數據庫角度看，每個SQL執行都需要消耗一定I/O資源，SQL執行的快慢，決定了資源被占用時間的長短。假如有一條慢SQL占用了30%的資源共計1分鐘。那么在這1分鐘時間內，其他SQL能夠分配的資源總量就是70%，如此循環，當資源分配完的時候，所有新的SQL執行將會排隊等待。所以往往一條慢SQL會影響到整個業務。
PolarDB-X中SQL的執行過程
在分析慢SQL之前，需要先了解SQL的執行過程。一條SQL的執行共涉及到三層，包含兩次網絡數據交換：客戶端到計算節點（CN）、計算節點到數據節點（DN）。
說明
灰色部分為不可下推的SQL語句的執行流程，包括解析、優化、調度、執行四大步驟。
淺綠色部分為可以下推的SQL語句的執行流程，主要過程是將數據節點（DN）的數據進行掃描和計算，并將數據通過私有遠程過程調用協議（Remote Procedure Call Protocol，RPC）返回給上層計算節點繼續做計算。
結合PolarDB-X數據庫的原理和SQL語句的執行過程，發現影響SQL語句執行效率的主要因素包括：
數據量
SQL執行后返回給客戶端的數據量的大小；
DN層數據量越大需要掃描的I/O次數越多，DN節點的IO更容易成為瓶頸。
取數據的方式
數據在緩存中還是在磁盤上；
是否能夠通過DN上的全局索引快速尋址；
是否結合謂詞條件命中全局索引加速掃描。
數據加工的方式
排序、子查詢、聚合、關聯等，一般需要先把數據取到臨時表中，再對數據進行加工；
對于數據量比較多的計算，會消耗大量計算節點的CPU資源，讓數據加工變得更加緩慢；
是否選擇了合適的關聯算法。
優化思路
將數據存放在更快的地方
某條查詢涉及到大表，無法進一步優化，如果返回的數據量不大且變化頻率不高但訪問頻率很高，此時應該考慮將返回的數據放在應用端的緩存當中或者Redis這樣的緩存當中，以提高存取速度。
關聯操作盡量將計算下推
如果業務大部分都是大表關聯操作，那么盡可能設計合理的分片策略。將分片的Key與關聯條件的Join Key對齊，PolarDB-X就會把這部分關聯操作轉化成可下推的物理SQL下推，避免單表掃描帶來的壓力；
如果涉及到的慢SQL是典型的大小表關聯，并且小表的數據為量不大且變化頻率不高的，那么可以把小表做成廣播表，這樣任何表和廣播表做關聯，都會被優化成可下推的物理SQL；
如果關聯涉及到的表分片策略無法變更，可以以Join Key為表創建全局二級索引，這樣關聯操作可以下推，在DN的索引表上做關聯。
減少數據掃描
盡量在查詢中加入一些可以提前過濾數據的謂詞條件，比如按照時間過濾數據等，可以減少數據的掃描量，對查詢更友好；
在掃描大表數據時是否可以命中索引，減少回表代價，避免全表掃描。
執行計劃中選擇更合理的數據加工算法
例如關聯算法有HashJoin、SortMergeJoin、BkaJoin等，每種關聯算法都有特定的場景，執行計劃選擇不合理，會影響到查詢代價。
定位慢SQL
通過命令
show slow和show physical_slow查看邏輯和物理慢SQL，通過指令只能定位到最近100條的慢SQL。執行以下命令：
show slow;返回信息如下：
+------------------+---------------+-----------+---------------------+--------------+------------+--------------------+ | TRACE_ID | USER | HOST | START_TIME | EXECUTE_TIME | AFFECT_ROW | SQL | +------------------+---------------+-----------+---------------------+--------------+------------+--------------------+ | 12f812912f400000 | polardbx_root | 127.0.0.1 | 2021-08-24 12:59:38 | 6475 | 0 | show physical_slow | | 12f8128383400000 | polardbx_root | 127.0.0.1 | 2021-08-24 12:59:19 | 1899 | -1 | show physical_slow | +------------------+---------------+-----------+---------------------+--------------+------------+--------------------+ 2 rows in set (0.01 sec)執行以下命令：
show physical_slow;返回信息如下：
+----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+ | GROUP_NAME | DBKEY_NAME | START_TIME | EXECUTE_TIME | SQL_EXECUTE_TIME | GETLOCK_CONNECTION_TIME | CREATE_CONNECTION_TIME | AFFECT_ROW | SQL | +----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+ | TDDL5_00_GROUP | db218249098_sqa_zmf_tddl5_00_3309 | 2021-03-16 13:05:38 | 1057 | 1011 | 0 | 0 | 1 | select sleep(1) | +----------------+-----------------------------------+---------------------+--------------+------------------+-------------------------+------------------------+------------+-----------------+ 1 row in set (0.01 sec)
分析慢SQL
慢SQL產生的原因主要包括以下三大類：
業務問題：明顯的數據傾斜、不合理的分片策略設置、數據返回過多等和業務使用相關問題；
系統問題：流量太大，資源成為瓶頸或者網絡抖動造成的問題；
執行問題：如選錯索引，選錯Join類型或順序等問題。
從業務角度分析
如果慢SQL本身是簡單查詢，但掃描返回的數據本身是十幾萬或者上百萬行，這個是符合預期的，需要從業務上判斷是否真的需要返回那么多條數據；
如果某類SQL出現慢SQL只是針對于特定分區鍵的值和區間，可以通過
show info from T語句，確認是否有數據傾斜問題，是否可以調整分片策略。
執行以下語句：
show table info from test_tb;返回信息如下：
+----+------------+-----------------+------------+
| ID | GROUP_NAME | TABLE_NAME | SIZE_IN_MB |
+----+------------+-----------------+------------+
| 0 | ads_000000 | test_tb_o2ud_00 | 0.01562500 |
| 1 | ads_000000 | test_tb_o2ud_01 | 0.01562500 |
| 2 | ads_000000 | test_tb_o2ud_02 | 0.01562500 |
| 3 | ads_000000 | test_tb_o2ud_03 | 0.01562500 |
| 4 | ads_000000 | test_tb_o2ud_04 | 0.01562500 |
+----+------------+-----------------+------------+從系統角度分析
慢SQL出現時會伴隨著業務流量上漲，可以先去控制臺查看對應時間點的計算和存儲上的資源監控，判斷是否存在資源被打滿，如果是由于業務流量上漲，導致資源被打滿，出現慢SQL是合理現象，可以考慮做資源擴容或者采取SQL限流。
如果從慢日志查看不到慢SQL，但是從業務上確實受到慢SQL影響，且已經排除掉了是業務自身問題，這個時候可以查看是否是網絡問題，確認下客戶端和服務端是否處于一個VPC網絡或者通過抓包進一步分析。
從執行角度分析
PolarDB-X提供了豐富的explain指令，來排查是否是查詢本身導致的慢SQL。
查看邏輯執行計劃
執行
explain語句，查看邏輯執行計劃。explain select nation, o_year, sum(amount) as sum_profit from ( select n_name as nation, extract(year from o_orderdate) as o_year, l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount from part, supplier, lineitem, partsupp, orders, nation where s_suppkey = l_suppkey and ps_suppkey = l_suppkey and ps_partkey = l_partkey and p_partkey = l_partkey and o_orderkey = l_orderkey and s_nationkey = n_nationkey and p_name like '%yellow%' ) as profit group by nation, o_year order by nation, o_year desc limit 1;返回信息如下：
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | LOGICAL EXECUTIONPLAN | +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Limit(offset=0, fetch=?2) | | SortAgg(group="nation,o_year", $f2="SUM(amount)") | | Project(nation="N_NAME", o_year="EXTRACT", amount="__*__ - PS_SUPPLYCOST * L_QUANTITY") | | HashJoin(condition="PS_PARTKEY = L_PARTKEY AND P_PARTKEY = L_PARTKEY AND PS_SUPPKEY = L_SUPPKEY AND PS_SUPPKEY = S_SUPPKEY", type="inner") | | MemSort(sort="N_NAME ASC,EXTRACT DESC") | | BKAJoin(condition="O_ORDERKEY = L_ORDERKEY", type="inner") | | Project(S_SUPPKEY="S_SUPPKEY", S_NATIONKEY="S_NATIONKEY", N_NATIONKEY="N_NATIONKEY", N_NAME="N_NAME", L_ORDERKEY="L_ORDERKEY", L_PARTKEY="L_PARTKEY", L_SUPPKEY="L_SUPPKEY", L_QUANTITY="L_QUANTITY", __*__="__*__") | | HashJoin(condition="L_SUPPKEY = S_SUPPKEY", type="inner") | | Gather(concurrent=true) | | LogicalView(tables="[000000-000003].lineitem_[00-15]", shardCount=16, sql="SELECT `L_ORDERKEY`, `L_PARTKEY`, `L_SUPPKEY`, `L_QUANTITY`, (`L_EXTENDEDPRICE` * (? - `L_DISCOUNT`)) AS `__*__` FROM `lineitem` AS `lineitem`") | | BKAJoin(condition="N_NATIONKEY = S_NATIONKEY", type="inner") | | Gather(concurrent=true) | | LogicalView(tables="[000000-000003].supplier_[00-15]", shardCount=16, sql="SELECT `S_SUPPKEY`, `S_NATIONKEY` FROM `supplier` AS `supplier`") | | Gather(concurrent=true) | | LogicalView(tables="[000000-000003].nation_[00-15]", shardCount=16, sql="SELECT `N_NATIONKEY`, `N_NAME` FROM `nation` AS `nation` WHERE (`N_NATIONKEY` IN (...))") | | Gather(concurrent=true) | | LogicalView(tables="[000000-000003].orders_[00-15]", shardCount=16, sql="SELECT `O_ORDERKEY`, EXTRACT(YEAR FROM `O_ORDERDATE`) AS `EXTRACT` FROM `orders` AS `orders` WHERE (`O_ORDERKEY` IN (...))") | | Gather(concurrent=true) | | LogicalView(tables="[000000-000003].part_[00-15],partsupp_[00-15]", shardCount=16, sql="SELECT `part`.`P_PARTKEY`, `partsupp`.`PS_PARTKEY`, `partsupp`.`PS_SUPPKEY`, `partsupp`.`PS_SUPPLYCOST` FROM `part` AS `part` INNER JOIN `partsupp` AS `partsupp` ON ((`part`.`P_PARTKEY` = `partsupp`.`PS_PARTKEY`) AND (`part`.`P_NAME` LIKE ?)) WHERE (`partsupp`.`PS_PARTKEY` = `part`.`P_PARTKEY`)") | | HitCache:false | | Source:PLAN_CACHE說明LogicalView里的shardCount參數表示需訪問的分表總數。
根據執行計劃分析SQL執行過程是否符合預期，主要關注全局二級索引、聚合優化和執行和JOIN優化和執行選擇是否合理，執行計劃的優劣直接影響到執行快慢。如果確認是優化過程中的執行計劃不合理的話，可以按照下面三種方式去解決：
執行計劃的生成是基于統計信息的，如果統計信息缺失和過期，有可能導致優化出來的執行計劃不是最佳的。可以通過
analyze table語句手動觸發統計信息收集。執行以下語句，查看統計信息是否被正確收集。
show statistic;返回信息如下：
+---------------+------------+-------------+-------------+ | table_name | table_rows | column_name | cardinality | +---------------+------------+-------------+-------------+ | tpch_orders | 8400 | NULL | NULL | | tpch_lineitem | 10000 | NULL | NULL | | lineitem | 8492 | NULL | NULL | | tpch_part | 8054 | NULL | NULL | | aa_lineitem | 8490 | l_id | 9143 | | part | 8054 | NULL | NULL | | not_rt | 8446 | NULL | NULL | | aa_orders | 8308 | o_id | 9095 | | partsupp | 8609 | NULL | NULL | | aa_partsupp | 8667 | ps_id | 9424 | | tpch_partsupp | 8596 | NULL | NULL | | tpch_customer | 8572 | NULL | NULL | | orders | 8423 | NULL | NULL | | aa_customer | 9080 | c_id | 9476 | | customer | 8472 | NULL | NULL | +---------------+------------+-------------+-------------+ 15 rows in set (0.01 sec)執行以下語句，指定表名手動收集統計信息：
analyze table lineitem;返回信息如下：
+--------------+---------+----------+----------+ | TABLE | OP | MSG_TYPE | MSG_TEXT | +--------------+---------+----------+----------+ | ads.lineitem | analyze | status | OK | +--------------+---------+----------+----------+ 1 row in set (1.66 sec)在統計信息合理的基礎上，優化器生成的執行計劃可能還不是最優的。因為優化器的優化過程實際上是利用動態規劃算子尋找相對最優解的過程，存在一定的不確定性。所以可以通過
HINT force index手動制定最佳執行計劃。
查看物理執行計劃
執行
explain execute語句，查看下推SQL在DN上執行的計劃，主要用于確認在DN上的執行是否選擇了合適的局部索引。同樣可以通過force index指令強制指定索引，選擇合適的局部索引可以加快下推SQL在DN上的掃描效率。示例1：
explain execute select * from lineitem;返回信息如下：
+----+-------------+----------+------------+------+---------------+-----+---------+-----+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------------+------+---------------+-----+---------+-----+------+----------+-------+ | 1 | SIMPLE | lineitem | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100 | NULL | +----+-------------+----------+------------+------+---------------+-----+---------+-----+------+----------+-------+ 1 row in set (0.02 sec)示例2：
explain execute select L_LINENUMBER from lineitem;返回信息如下：
+----+-------------+----------+------------+-------+---------------+---------+---------+-----+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------------+-------+---------------+---------+---------+-----+------+----------+-------------+ | 1 | SIMPLE | lineitem | NULL | index | NULL | PRIMARY | 8 | NULL | 1 | 100 | Using index | +----+-------------+----------+------------+-------+---------------+---------+---------+-----+------+----------+-------------+ 1 row in set (0.04 sec)分析查詢耗時
如果一條SQL每次執行都很慢，可以通過
explain analyze語句分析查詢到底慢在哪個算子上，方便準確分析出查詢耗時的原因，從而有針對性的解決。explain analyze select L_SUPPKEY, count(*) from lineitem group by L_SUPPKEY;返回信息如下：
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | LOGICAL EXECUTIONPLAN | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | HashAgg(group="L_SUPPKEY", count(*)="SUM(count(*))"): rowcount = 1000.0, cumulative cost = value = 2.4863085E7, cpu = 108049.0, memory = 35480.0, io = 201.0, net = 4.75, actual time = 0.000 + 0.000, actual rowcount = 1000, actual memory = 0, instances = 1, id = 519 | | Gather(concurrent=true): rowcount = 1000.0, cumulative cost = value = 2.4860051E7, cpu = 105039.0, memory = 11881.0, io = 201.0, net = 4.75, actual time = 0.000 + 0.000, actual rowcount = 0, actual memory = 0, instances = 0, id = 517 | | LogicalView(tables="[000000-000003].lineitem_[00-15]", shardCount=16, sql="SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM `lineitem` AS `lineitem` GROUP BY `L_SUPPKEY`"): rowcount = 1000.0, cumulative cost = value = 2.486005E7, cpu = 105038.0, memory = 11881.0, io = 201.0, net = 4.75, actual time = 0.004 + 0.002, actual rowcount = 4892, actual memory = 0, instances = 0, id = 453 |參數說明：
rowcount：基于統計信息預估的算子輸出行數；
actual rowcount：真實執行過程中算子實際輸出函數；
actual time：真實執行過程中算子實際耗時。
如果是并發度不夠，可以通過調整并發度加速查詢。此外還可以通過trace指令，準確知道真實的下推物理SQL和耗時，明確耗時長是發生在CN層還是DN層。
執行以下命令：
trace select L_SUPPKEY, count(*) from lineitem group by L_SUPPKEY limit 1;說明TRACE指令需要在MySQL客戶端上執行，如果您的服務器尚未安裝MySQL客戶端，請前往MySQL網站下載安裝。返回信息如下：
+-----------+----------+ | L_SUPPKEY | count(*) | +-----------+----------+ | 1 | 12 | +-----------+----------+ 1 row in set (0.21 sec)執行以下命令：
show trace;返回信息如下：
+----+----------------+-----------+-------+------------------+----------------------------------------------------------------------------+---------------+--------------------------+---------------------+---------------------+------+-------------------------------------------------------------------------------------------------------------------------------+----------------------+ | ID | NODE_IP | TIMESTAMP | TYPE | GROUP_NAME | DBKEY_NAME | TIME_COST(MS) | CONNECTION_TIME_COST(MS) | TOTAL_TIME_COST(MS) | CLOSE_TIME_COST(MS) | ROWS | STATEMENT | PARAMS | +----+----------------+-----------+-------+------------------+----------------------------------------------------------------------------+---------------+--------------------------+---------------------+---------------------+------+-------------------------------------------------------------------------------------------------------------------------------+----------------------+ | 0 | 192.168.31.105 | 0.000 | Query | ADS_000003_GROUP | dskey_ads_000003_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000003 | 3 | 0.00 | 3 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_13`] | | 1 | 192.168.31.105 | -0.000 | Query | ADS_000003_GROUP | dskey_ads_000003_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000003 | 4 | 0.00 | 7 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_12`] | | 2 | 192.168.31.105 | 0.000 | Query | ADS_000003_GROUP | dskey_ads_000003_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000003 | 2 | 0.00 | 2 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_14`] | | 3 | 192.168.31.105 | 0.000 | Query | ADS_000003_GROUP | dskey_ads_000003_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000003 | 3 | 0.00 | 3 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_15`] | | 4 | 192.168.31.105 | 0.000 | Query | ADS_000001_GROUP | dskey_ads_000001_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000001 | 5 | 0.00 | 14 | 2 | 746 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_04`] | | 5 | 192.168.31.105 | 0.000 | Query | ADS_000001_GROUP | dskey_ads_000001_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000001 | 4 | 0.00 | 15 | 1 | 682 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_05`] | | 6 | 192.168.31.105 | 0.000 | Query | ADS_000001_GROUP | dskey_ads_000001_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000001 | 9 | 0.00 | 15 | 1 | 516 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_06`] | | 7 | 192.168.31.105 | 0.000 | Query | ADS_000001_GROUP | dskey_ads_000001_group#polardbx-storage-1-master#127.0.0.1-3306#ads_000001 | 7 | 0.00 | 15 | 0 | 310 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_07`] | | 8 | 192.168.31.105 | 0.000 | Query | ADS_000000_GROUP | dskey_ads_000000_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000000 | 2 | 0.00 | 3 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_00`] | | 9 | 192.168.31.105 | 0.000 | Query | ADS_000000_GROUP | dskey_ads_000000_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000000 | 5 | 0.00 | 7 | 1 | 884 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_02`] | | 10 | 192.168.31.105 | 0.000 | Query | ADS_000002_GROUP | dskey_ads_000002_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000002 | 2 | 0.00 | 5 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_08`] | | 11 | 192.168.31.105 | 0.000 | Query | ADS_000000_GROUP | dskey_ads_000000_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000000 | 6 | 0.00 | 11 | 0 | 917 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_01`] | | 12 | 192.168.31.105 | 0.000 | Query | ADS_000000_GROUP | dskey_ads_000000_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000000 | 7 | 0.00 | 10 | 1 | 837 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_03`] | | 13 | 192.168.31.105 | 0.000 | Query | ADS_000002_GROUP | dskey_ads_000002_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000002 | 3 | 0.00 | 3 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_09`] | | 14 | 192.168.31.105 | 0.000 | Query | ADS_000002_GROUP | dskey_ads_000002_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000002 | 2 | 0.00 | 2 | 0 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_10`] | | 15 | 192.168.31.105 | 0.000 | Query | ADS_000002_GROUP | dskey_ads_000002_group#polardbx-storage-0-master#127.0.0.1-3306#ads_000002 | 1 | 0.00 | 3 | 1 | 0 | /*DRDS /127.0.0.1/12f940ed62400000/0// */SELECT `L_SUPPKEY`, COUNT(*) AS `count(*)` FROM ? AS `lineitem` GROUP BY `L_SUPPKEY` | [`lineitem_MgSG_11`] | +----+----------------+-----------+-------+------------------+----------------------------------------------------------------------------+---------------+--------------------------+---------------------+---------------------+------+-------------------------------------------------------------------------------------------------------------------------------+----------------------+ 16 rows in set (0.05 sec)
文檔內容是否對您有幫助？