Табличка:

mysql> show create table mobile_stat_device\G
*************************** 1. row ***************************
       Table: mobile_stat_device
Create Table: CREATE TABLE `mobile_stat_device` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `deviceUuid` char(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'Unique device ID',
  `deviceUuidHash` int unsigned GENERATED ALWAYS AS (crc32(`deviceUuid`)) STORED NOT NULL,
  `createdAt` datetime NOT NULL COMMENT 'Inserting date',
  PRIMARY KEY (`id`),
  UNIQUE KEY `deviceUuid_udx` (`deviceUuidHash`,`deviceUuid`),
  KEY `deviceUuidHash_idx` (`deviceUuidHash`)
) ENGINE=InnoDB AUTO_INCREMENT=2490316 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.00 sec)

Старый добрый count:

mysql> select count(1) from mobile_stat_device\G
*************************** 1. row ***************************
count(1): 2097152
1 row in set (2.20 sec)

Старый добрый sum:

mysql> select sum(1) from mobile_stat_device\G
*************************** 1. row ***************************
sum(1): 2097152
1 row in set (0.97 sec)

SUM быстрее COUNT более чем в два раза.

При том, что планы выполнения совпадают до буквы.

mysql> explain format=json select count(1) from mobile_stat_device\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "213393.07"
    },
    "table": {
      "table_name": "mobile_stat_device",
      "access_type": "index",
      "key": "deviceUuidHash_idx",
      "used_key_parts": [
        "deviceUuidHash"
      ],
      "key_length": "4",
      "rows_examined_per_scan": 2088550,
      "rows_produced_per_join": 2088550,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "4538.07",
        "eval_cost": "208855.00",
        "prefix_cost": "213393.07",
        "data_read_per_join": "318M"
      }
    }
  }
}
1 row in set, 1 warning (0.00 sec)

mysql> explain format=json select sum(1) from mobile_stat_device\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "213393.07"
    },
    "table": {
      "table_name": "mobile_stat_device",
      "access_type": "index",
      "key": "deviceUuidHash_idx",
      "used_key_parts": [
        "deviceUuidHash"
      ],
      "key_length": "4",
      "rows_examined_per_scan": 2088550,
      "rows_produced_per_join": 2088550,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "4538.07",
        "eval_cost": "208855.00",
        "prefix_cost": "213393.07",
        "data_read_per_join": "318M"
      }
    }
  }
}
1 row in set, 1 warning (0.00 sec)

Создадим тестовую табличку:

mysql> create table test_ai(
    ->     id int primary key not null auto_increment,
    ->     alias varchar(255) not null,
    ->     unique index (alias)
    -> );
Query OK, 0 rows affected (0.04 sec)

Главное, что в ней есть - это уникальный ключ, по полю alias

Вставим три записи

mysql> insert into test_ai(alias) values ('alias1'), ('alias2'), ('alias3');
Query OK, 3 rows affected (0.00 sec)

Посмотрим значение auto_increment в табличке

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Всё вроде верно. Мы вставили 3 записи и следующее значение id будет равно 4.

Теперь начинается интересное. Попробуем выполнить такую же вставку что и предыдущая.

mysql> insert into test_ai(alias) values ('alias1'), ('alias2'), ('alias3');
ERROR 1062 (23000): Duplicate entry 'alias1' for key 'test_ai.alias'

Ожидаемо, получим ошибку. Посмотрим опять на значение auto_increment

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.01 sec)

7! То есть mysql сначала увеличивает счетчик, а потом вставляет. Ладно, подавим ошибку и еще раз вставим.

mysql> insert ignore into test_ai(alias) values ('alias1'), ('alias2'), ('alias3');
Query OK, 0 rows affected, 3 warnings (0.02 sec)
Records: 3  Duplicates: 3  Warnings: 3

И посмотрим.

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

10! То есть автоинкремент увеличивается в любом случае.

Попробуем replace.

mysql> replace into test_ai(alias) values ('alias1'), ('alias2'), ('alias3');
Query OK, 6 rows affected (0.00 sec)
Records: 3  Duplicates: 3  Warnings: 0

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

Replace с одним валидным значением.

mysql> replace into test_ai(alias) values ('alias1'), ('alias2'), ('alias3'), ('alias4');
Query OK, 7 rows affected (0.01 sec)
Records: 4  Duplicates: 3  Warnings: 0

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

При этом ID поменялись, что логично. Но про replace и его принцип работы, как-нибудь в другой раз.

mysql> select * from test_ai
    -> ;
+----+--------+
| id | alias  |
+----+--------+
| 13 | alias1 |
| 14 | alias2 |
| 15 | alias3 |
| 16 | alias4 |
+----+--------+

И еще раз сделаем replace.

mysql> replace into test_ai(alias) values ('alias1'), ('alias2'), ('alias3'), ('alias4');
Query OK, 8 rows affected (0.02 sec)
Records: 4  Duplicates: 4  Warnings: 0

mysql> select * from test_ai;
+----+--------+
| id | alias  |
+----+--------+
| 17 | alias1 |
| 18 | alias2 |
| 19 | alias3 |
| 20 | alias4 |
+----+--------+

Попробуем обработать ошибку вставки через 'on duplicate key update'

mysql> insert into test_ai(alias) values ('alias1'), ('alias2'), ('alias3') on duplicate key update id = id;
Query OK, 0 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> show create table test_ai\G
*************************** 1. row ***************************
       Table: test_ai
Create Table: CREATE TABLE `test_ai` (
  `id` int NOT NULL AUTO_INCREMENT,
  `alias` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Вывод: не зависит успешно или неуспешно вставлены данные, в любом случае auto_increment будет ползти вверх. А значит, при достаточных объёмах вставляемых данных (с любым результатом) auto_increment очень быстро может достичь максимального значения для первичного ключа. Кроме того, необходимо учитывать возможную неравномерность распределения значений первичного ключа, например, в случае если необходимости по нему итерироваться.

В базах данных offset работает так: выбираются первые записи, где кол-во выбираемых записей равно offset+limit, потом записи до offset отбрасываются и остаток уже возвращается в запросе. Покажу на примере.

Как всегда, любимая табличка mobile_stat_device

mysql> show create table mobile_stat_device\G
*************************** 1. row ***************************
       Table: mobile_stat_device
Create Table: CREATE TABLE `mobile_stat_device` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `deviceUuid` char(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'Unique device ID',
  `deviceUuidHash` int unsigned GENERATED ALWAYS AS (crc32(`deviceUuid`)) STORED NOT NULL,
  `createdAt` datetime NOT NULL COMMENT 'Inserting date',
  PRIMARY KEY (`id`),
  UNIQUE KEY `deviceUuid_udx` (`deviceUuidHash`,`deviceUuid`),
  KEY `deviceUuidHash_idx` (`deviceUuidHash`)
) ENGINE=InnoDB AUTO_INCREMENT=2490316 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

С большим количеством записей

mysql> select count(1) from mobile_stat_device;
+----------+
| count(1) |
+----------+
|  2097152 |
+----------+

Запрос, который выполняется почти секунду:

mysql> select SQL_NO_CACHE * from mobile_stat_device order by id limit 10 offset 2050000;
+---------+--------------------------------------+----------------+---------------------+
| id      | deviceUuid                           | deviceUuidHash | createdAt           |
+---------+--------------------------------------+----------------+---------------------+
| 2377645 | 370f4d5e-519b-11eb-a85f-42010a9c0002 |     1792791173 | 2021-01-08 10:21:03 |
| 2377646 | 370f4d6c-519b-11eb-a85f-42010a9c0002 |     3206227716 | 2021-01-08 10:21:03 |
| 2377647 | 370f4d7b-519b-11eb-a85f-42010a9c0002 |     3766230312 | 2021-01-08 10:21:03 |
| 2377648 | 370f4d89-519b-11eb-a85f-42010a9c0002 |     2525345549 | 2021-01-08 10:21:03 |
| 2377649 | 370f4d98-519b-11eb-a85f-42010a9c0002 |     3387067681 | 2021-01-08 10:21:03 |
| 2377650 | 370f4da6-519b-11eb-a85f-42010a9c0002 |     2785299536 | 2021-01-08 10:21:03 |
| 2377651 | 370f4db5-519b-11eb-a85f-42010a9c0002 |     1202520612 | 2021-01-08 10:21:03 |
| 2377652 | 370f4dc3-519b-11eb-a85f-42010a9c0002 |     3937153461 | 2021-01-08 10:21:03 |
| 2377653 | 370f4dd2-519b-11eb-a85f-42010a9c0002 |     1015628201 | 2021-01-08 10:21:03 |
| 2377654 | 370f4de1-519b-11eb-a85f-42010a9c0002 |     2783037901 | 2021-01-08 10:21:03 |
+---------+--------------------------------------+----------------+---------------------+
10 rows in set, 1 warning (0.50 sec)

С очень любопытным explain:

mysql> explain format=json select SQL_NO_CACHE * from mobile_stat_device order by id limit 10 offset 2050000\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "213695.60"
    },
    "ordering_operation": {
      "using_filesort": false,
      "table": {
        "table_name": "mobile_stat_device",
        "access_type": "index",
        "key": "PRIMARY",
        "used_key_parts": [
          "id"
        ],
        "key_length": "4",
        "rows_examined_per_scan": 2050010,
        "rows_produced_per_join": 2088550,
        "filtered": "100.00",
        "cost_info": {
          "read_cost": "4840.61",
          "eval_cost": "208855.00",
          "prefix_cost": "213695.61",
          "data_read_per_join": "318M"
        },
        "used_columns": [
          "id",
          "deviceUuid",
          "deviceUuidHash",
          "createdAt"
        ]
      }
    }
  }
}

Для того, что бы отдать 680 байт mysql прочитал 318 мегабайт. Кол-во затронутых записей rows_examined_per_scan = 2050010 = 2050000(offset) + 10(limit)

И что самое плохое в этом запросе - с увеличением offset производительность и дальше будет деградировать.

Как быть?

В данном конкретном случае, можно воспользоваться тем, что id идут по порядку и переписать запрос так

mysql> select SQL_NO_CACHE * from mobile_stat_device where id between 2377645 and 2377654 order by id;
+---------+--------------------------------------+----------------+---------------------+
| id      | deviceUuid                           | deviceUuidHash | createdAt           |
+---------+--------------------------------------+----------------+---------------------+
| 2377645 | 370f4d5e-519b-11eb-a85f-42010a9c0002 |     1792791173 | 2021-01-08 10:21:03 |
| 2377646 | 370f4d6c-519b-11eb-a85f-42010a9c0002 |     3206227716 | 2021-01-08 10:21:03 |
| 2377647 | 370f4d7b-519b-11eb-a85f-42010a9c0002 |     3766230312 | 2021-01-08 10:21:03 |
| 2377648 | 370f4d89-519b-11eb-a85f-42010a9c0002 |     2525345549 | 2021-01-08 10:21:03 |
| 2377649 | 370f4d98-519b-11eb-a85f-42010a9c0002 |     3387067681 | 2021-01-08 10:21:03 |
| 2377650 | 370f4da6-519b-11eb-a85f-42010a9c0002 |     2785299536 | 2021-01-08 10:21:03 |
| 2377651 | 370f4db5-519b-11eb-a85f-42010a9c0002 |     1202520612 | 2021-01-08 10:21:03 |
| 2377652 | 370f4dc3-519b-11eb-a85f-42010a9c0002 |     3937153461 | 2021-01-08 10:21:03 |
| 2377653 | 370f4dd2-519b-11eb-a85f-42010a9c0002 |     1015628201 | 2021-01-08 10:21:03 |
| 2377654 | 370f4de1-519b-11eb-a85f-42010a9c0002 |     2783037901 | 2021-01-08 10:21:03 |
+---------+--------------------------------------+----------------+---------------------+
10 rows in set, 1 warning (0.00 sec)

Explain:

mysql> explain format=json select SQL_NO_CACHE * from mobile_stat_device where id between 2377645 and 2377654 order by id\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "2.57"
    },
    "ordering_operation": {
      "using_filesort": false,
      "table": {
        "table_name": "mobile_stat_device",
        "access_type": "range",
        "possible_keys": [
          "PRIMARY"
        ],
        "key": "PRIMARY",
        "used_key_parts": [
          "id"
        ],
        "key_length": "4",
        "rows_examined_per_scan": 10,
        "rows_produced_per_join": 10,
        "filtered": "100.00",
        "cost_info": {
          "read_cost": "1.57",
          "eval_cost": "1.00",
          "prefix_cost": "2.57",
          "data_read_per_join": "1K"
        },
        "used_columns": [
          "id",
          "deviceUuid",
          "deviceUuidHash",
          "createdAt"
        ],
        "attached_condition": "(`test`.`mobile_stat_device`.`id` between 2377645 and 2377654)"
      }
    }
  }
}

Вот, стало значительно веселее.

Если необходимо пробежаться по всем записям таблички чтобы, например, сделать экспорт, то можно использовать условие id > самого большого id прошлой выборки, но id <= самого большого id прошлой выборки + limit + 1. Условием остановки итераций будет значение id >= максимального значения id

Запросы для отображения по страницам - для чего обычно и используют лимиты и офсеты, тут смысла не имеют из-за большого количества данных. Если же наложить какие-то внешние фильтры, уменьшив там самым кол-во выбираемых данных, то и offset будет работать быстро.

Есть вот такая табличка:

mysql> show create table mobile_stat_device\G
*************************** 1. row ***************************
       Table: mobile_stat_device
Create Table: CREATE TABLE `mobile_stat_device` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `deviceUuid` char(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'Unique device ID',
  `deviceUuidHash` int unsigned GENERATED ALWAYS AS (crc32(`deviceUuid`)) STORED NOT NULL,
  `createdAt` datetime NOT NULL COMMENT 'Inserting date',
  PRIMARY KEY (`id`),
  UNIQUE KEY `deviceUuid_udx` (`deviceUuidHash`,`deviceUuid`),
  KEY `deviceUuidHash_idx` (`deviceUuidHash`)
) ENGINE=InnoDB AUTO_INCREMENT=2490316 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Табличка с uuid устройств. Для ускорения запросов добавлено поле deviceUuidHash и создан комбинированный уникальный индекс по полям deviceUuidHash и deviceUuid.

Кол-во записей в mobile_stat_device чуть больше 2х миллионов:

mysql> select count(1) from mobile_stat_device;
+----------+
| count(1) |
+----------+
|  2097152 |
+----------+

Нам необходимо выбрать id для определенных uuid устройств. Мой первый запрос выглядел вот так:

mysql> select id, deviceUuid from mobile_stat_device where 
(deviceUuid = '36fffc8d-519b-11eb-a85f-42010a9c0002' and deviceUuidHash = crc32(deviceUuid)) or
(deviceUuid = '36fffd73-519b-11eb-a85f-42010a9c0002' and deviceUuidHash = crc32(deviceUuid));
+---------+--------------------------------------+
| id      | deviceUuid                           |
+---------+--------------------------------------+
| 2327645 | 36fffc8d-519b-11eb-a85f-42010a9c0002 |
| 2327653 | 36fffd73-519b-11eb-a85f-42010a9c0002 |
+---------+--------------------------------------+

Посмотрев на explain, я успокоился - индекс используется, ну и ладно

mysql> explain select id, deviceUuid from mobile_stat_device where (deviceUuid = '36fffc8d-519b-11eb-a85f-42010a9c0002' and deviceUuidHash=crc32(deviceUuid)) or (deviceUuid = '36fffd73-519b-11eb-a85f-42010a9c0002' and deviceUuidHash = crc32(deviceUuid));
+----+-------------+--------------------+------------+-------+---------------+----------------+---------+------+---------+----------+--------------------------+
| id | select_type | table              | partitions | type  | possible_keys | key            | key_len | ref  | rows    | filtered | Extra                    |
+----+-------------+--------------------+------------+-------+---------------+----------------+---------+------+---------+----------+--------------------------+
|  1 | SIMPLE      | mobile_stat_device | NULL       | index | NULL          | deviceUuid_udx | 148     | NULL | 2088550 |     1.99 | Using where; Using index |
+----+-------------+--------------------+------------+-------+---------------+----------------+---------+------+---------+----------+--------------------------+

Я не обратил внимание на количество rows в эксплейне. Точнее, когда данных мало, то и кол-во rows приемлемое. Ошибочность запроса стала понятна только когда нагрузил данными табличку и еще раз проверил скорость запроса.

Вот тот же explain в более информативном виде.

mysql> explain format=json select id, deviceUuid from mobile_stat_device where (deviceUuid = '36fffc8d-519b-11eb-a85f-42010a9c0002' and deviceUuidHash=crc32(deviceUuid)) or (deviceUuid = '36fffd73-519b-11eb-a85f-42010a9c0002' and deviceUuidHash = crc32(deviceUuid))\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "216917.41"
    },
    "table": {
      "table_name": "mobile_stat_device",
      "access_type": "index",
      "key": "deviceUuid_udx",
      "used_key_parts": [
        "deviceUuidHash",
        "deviceUuid"
      ],
      "key_length": "148",
      "rows_examined_per_scan": 2088550,
      "rows_produced_per_join": 41562,
      "filtered": "1.99",
      "using_index": true,
      "cost_info": {
        "read_cost": "212761.19",
        "eval_cost": "4156.21",
        "prefix_cost": "216917.41",
        "data_read_per_join": "6M"
      },
      "used_columns": [
        "id",
        "deviceUuid",
        "deviceUuidHash"
      ],
      "attached_condition": "(((`test`.`mobile_stat_device`.`deviceUuid` = '36fffc8d-519b-11eb-a85f-42010a9c0002') and (`test`.`mobile_stat_device`.`deviceUuidHash` = crc32(`test`.`mobile_stat_device`.`deviceUuid`))) or ((`test`.`mobile_stat_device`.`deviceUuid` = '36fffd73-519b-11eb-a85f-42010a9c0002') and (`test`.`mobile_stat_device`.`deviceUuidHash` = crc32(`test`.`mobile_stat_device`.`deviceUuid`))))"
    }
  }
}

О чём это говорит? Запрос пробегает по 2088550 записям и для ответа использует 41562. А так быть не должно. Где-то ошибка.

Внимательный читатель уже догадался где. Вот в этом условии - and deviceUuidHash = crc32(deviceUuid). Похоже, MySQL сначала вычисляет значение crc32 для всех записей, а потом уже, используя индекс, делается селект.

Переписанный запрос.

mysql> explain format=json select id, deviceUuid from mobile_stat_device
where (deviceUuid = '36fffc8d-519b-11eb-a85f-42010a9c0002' and 
deviceUuidHash=crc32('36fffc8d-519b-11eb-a85f-42010a9c0002')) or 
(deviceUuid = '36fffd73-519b-11eb-a85f-42010a9c0002' and 
deviceUuidHash = crc32('36fffd73-519b-11eb-a85f-42010a9c0002'))\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "0.85"
    },
    "table": {
      "table_name": "mobile_stat_device",
      "access_type": "range",
      "possible_keys": [
        "deviceUuid_udx",
        "deviceUuidHash_idx"
      ],
      "key": "deviceUuid_udx",
      "used_key_parts": [
        "deviceUuidHash",
        "deviceUuid"
      ],
      "key_length": "148",
      "rows_examined_per_scan": 2,
      "rows_produced_per_join": 2,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "0.65",
        "eval_cost": "0.20",
        "prefix_cost": "0.85",
        "data_read_per_join": "320"
      },
      "used_columns": [
        "id",
        "deviceUuid",
        "deviceUuidHash"
      ],
      "attached_condition": "(((`test`.`mobile_stat_device`.`deviceUuidHash` = <cache>(crc32('36fffc8d-519b-11eb-a85f-42010a9c0002'))) and (`test`.`mobile_stat_device`.`deviceUuid` = '36fffc8d-519b-11eb-a85f-42010a9c0002')) or ((`test`.`mobile_stat_device`.`deviceUuidHash` = <cache>(crc32('36fffd73-519b-11eb-a85f-42010a9c0002'))) and (`test`.`mobile_stat_device`.`deviceUuid` = '36fffd73-519b-11eb-a85f-42010a9c0002')))"
    }
  }
}

Обратите внимание, насколько упал query_cost и насколько меньше записей выбирается.

Вывода два:

1. Быть осторожнее с вычислительными значениями в запросах, если эти значения используются в where.
2. Нагружать БД данными и потом уже проверять насколько корректно отрабатывают запросы.

Услуга нацелена прежде всего на разработчиков мобильных приложений, чтобы без всякого геморроя поднимать бэкенды для своих аппликух. Кроме обработчиков запросов имеется KV-хранилище и даже воркеры, которые работают по расписанию. Отладчик, песочница - всё в наличии. Что еще надо, чтобы поднять простенький бэкэнд?

А если учесть, что воркер может запускаться на тысячах машин распределенных по миру, выбирая наиболее близкую для клиента локацию, решение мне видится идеальным для быстрого старта.

И самое главное - вся эта красота бесплатна, если запросов меньше, чем 100 000 в день.

Однако, данную технологию могут использовать не только фронтендеры, но и все желающие, подключив фантазию. Например, можно прикрутить собственный домен для notion.

Я же на коленке написал воркер, который отдаёт код конвертера и добавил его в статью teletype через iframe. Вот что получилось:

Сформированный код необходимо вставить в блок iframe телетайпа и всё должно работать ;-)

Поправить следующий код, указав правильные размеры и embed код на нужный гист. Не забыть заменить в коде гиста двойные кавычки на одинарные.

UPD: Если руками делать не хочется, милости прошу, автоматическое средство

Разместить код в открывшемся окошке.