как оптимизировать количество (*) запросов на TIDB - PullRequest
Новая
       51

как оптимизировать количество (*) запросов на TIDB

0 голосов
/ 17 февраля 2020

У меня есть таблица с примерно 3000000 строками, описанными ниже. 

Field             |Type        |Null|Key|Default|Extra         |
------------------|------------|----|---|-------|--------------|
id                |bigint(20)  |NO  |PRI|       |auto_increment|
entity_name       |varchar(50) |YES |   |       |              |
field_type        |varchar(50) |YES |MUL|       |              |
kv_key            |text        |YES |MUL|       |              |
kv_value          |text        |YES |MUL|       |              |
value_type        |int(11)     |YES |   |       |              | 
dataset_id        |varchar(255)|YES |MUL|       |              |
dataset_version_id|varchar(255)|YES |MUL|       |              |
experiment_id     |varchar(255)|YES |MUL|       |              |
experiment_run_id |varchar(255)|YES |MUL|       |              |
job_id            |varchar(255)|YES |MUL|       |              |
project_id        |varchar(255)|YES |MUL|       |              |

Она имеет индексы в виде 

Table   |Non_unique|Key_name     |Seq_in_index|Column_name       |Collation|Cardinality|Sub_part|Packed|Null|Index_type|Comment|Index_comment|
--------|----------|-------------|------------|------------------|---------|-----------|--------|------|----|----------|-------|-------------|
keyvalue|         0|PRIMARY      |           1|id                |A        |          0|        |      |    |BTREE     |       |             |
keyvalue|         1|kv_dsv_id    |           1|dataset_version_id|A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_p_id      |           1|project_id        |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_j_id      |           1|job_id            |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_e_id      |           1|experiment_id     |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_d_id      |           1|dataset_id        |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_er_id     |           1|experiment_run_id |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_field_type|           1|field_type        |A        |          0|        |      |YES |BTREE     |       |             |
keyvalue|         1|kv_kv_val    |           1|kv_value          |A        |          0|     255|      |YES |BTREE     |       |             |
keyvalue|         1|kv_kv_key    |           1|kv_key            |A        |          0|     255|      |YES |BTREE     |       |             |

Объяснение возвращаемого значения выбора количества (*) в 178 мс с plan 

id                |count     |task|operator info                                                                |
------------------|----------|----|-----------------------------------------------------------------------------|
StreamAgg_48      |1.00      |root|funcs:count(col_0)                                                           |
└─IndexReader_49  |1.00      |root|index:StreamAgg_8                                                            |
  └─StreamAgg_8   |1.00      |cop |funcs:count(1)                                                               |
    └─IndexScan_39|2964754.00|cop |table:keyvalue, index:dataset_version_id, range:[NULL,+inf], keep order:false|

, а фактический запрос занимает около 2.6 sec.

trace format = 'row' select count(*) from keyvalue;

operation            |startTS        |duration    |
---------------------|---------------|------------|
session.getTxnFuture |20:21:00.074939|6.455µs     |
  ├─session.Execute  |20:21:00.074937|999.484µs   |
  ├─session.ParseSQL |20:21:00.074980|17.226µs    |
  ├─executor.Compile |20:21:00.075010|340.281µs   |
  ├─session.runStmt  |20:21:00.075370|525.307µs   |
  ├─session.CommitTxn|20:21:00.075882|3.542µs     |
  ├─recordSet.Next   |20:21:00.075946|2.585509798s|
  ├─streamAgg.Next   |20:21:00.075948|2.585497556s|
  ├─tableReader.Next |20:21:00.075950|2.585418751s|
  ├─tableReader.Next |20:21:02.661433|2.77µs      |
  ├─recordSet.Next   |20:21:02.661488|11.319µs    |
  └─streamAgg.Next   |20:21:02.661491|587ns       |

Моя настройка tidb выглядит следующим образом 

storage--tidb-discovery-f96cbd845-kgbvx                        1/1     Running   0          94d
storage--tidb-operator--controller-manager-fff86dd78-b7rmh     1/1     Running   0          3d19h
storage--tidb-pd-0                                             1/1     Running   0          3d18h
storage--tidb-pd-1                                             1/1     Running   0          3d18h
storage--tidb-pd-2                                             1/1     Running   0          3d18h
storage--tidb-tidb-0                                           2/2     Running   0          3d18h
storage--tidb-tidb-1                                           2/2     Running   0          3d18h
storage--tidb-tidb-initializer-9fff8f78d-gh4pr                 1/1     Running   0          3d22h
storage--tidb-tikv-0                                           1/1     Running   0          3d18h
storage--tidb-tikv-1                                           1/1     Running   0          3d18h
storage--tidb-tikv-2                                           1/1     Running   0          3d18h
storage--tidb-tikv-3                                           1/1     Running   0          3d18h

версия TIDB 

version()         |
------------------|
5.7.25-TiDB-v3.0.4|

Как я могу ускорить запрос? Мне также любопытно, почему запрос выбрал индекс, который он выбрал.

1 Ответ

1 голос
/ 18 февраля 2020

Я разработчик TiDB. На ваши вопросы:

  1. Как ускорить запрос?

    В таблице 3000000 строк, а SQL очень просто один. План исполнения уже лучший (с частичной агрегацией pu sh до TiKV). Поэтому я предлагаю вам увеличить некоторый параллелизм выполнения следующим образом: 

    tidb(localhost:4000) > show variables like "%concurrency%";
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| innodb_commit_concurrency          | 0     |
| innodb_concurrency_tickets         | 5000  |
| innodb_thread_concurrency          | 0     |
| thread_concurrency                 | 10    |
| tidb_build_stats_concurrency       | 4     |
| tidb_checksum_table_concurrency    | 4     |
| tidb_distsql_scan_concurrency      | 15    |
| tidb_hash_join_concurrency         | 5     |
| tidb_hashagg_final_concurrency     | 4     |
| tidb_hashagg_partial_concurrency   | 4     |
| tidb_index_lookup_concurrency      | 4     |
| tidb_index_lookup_join_concurrency | 4     |
| tidb_index_serial_scan_concurrency | 1     |
| tidb_opt_concurrency_factor        | 3     |
| tidb_projection_concurrency        | 4     |
| tidb_window_concurrency            | 4     |
+------------------------------------+-------+
16 rows in set (0.01 sec)

    Для вашего SQL, tidb_distsql_scan_concurrency может работать. Лучше установить его как (number of CPU cores / 8 * 15). Вы можете использовать set session/global tidb_distsql_scan_concurrency=?, чтобы изменить его.

  2. Почему запрос выбрал индекс?

    Поскольку count(*) эквивалентно count (1), байты индекса ключ-значение пара меньше, чем ключ-значение пара, отсканированная по плану TableScan. Есть некоторые блоги к сведению:

    TiDB Внутренний (I) - Хранение данных
    TiDB Внутренний (II) - Вычислительный
    TiDB Внутренний (III) - планирование

...