Alexander Rodionov IT

MySQL count VS sum

2021-01-28T08:12:57.786Z

Небольшое сравнение двух способов посчитать кол-во записей.

Табличка:

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

#sql

#оптимизация_запросов

AUTO_INCREMENT в MySQL

2021-01-22T08:19:58.597Z

Казалось бы, что может быть проще, чем автоинкремент в mysql. Но и с ним есть подводные камни и грабли, которые лучше знать и учитывать при проектировании баз данных.

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

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 очень быстро может достичь максимального значения для первичного ключа. Кроме того, необходимо учитывать возможную неравномерность распределения значений первичного ключа, например, в случае если необходимости по нему итерироваться.

#mysql

#оптимизация_запросов

Оптимизация OFFSET в MySQL

2021-01-11T10:32:34.741Z

Штука вроде очевидная, но всё же стоит её записать.

В базах данных 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

#sql

#оптимизация_запросов

MySQL. История одного медленного запроса

2021-01-08T11:38:07.217Z

SQL запросы иногда бывают не оптимизированы, из-за неправильного понимания механизмов работы

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

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 и насколько меньше записей выбирается.

Вывода два:

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

#mysql

#sql

#оптимизация_запросов

Cloudflare workers - хорошее решение для быстрого старта.

2021-01-04T08:37:36.218Z

Вы наверняка знаете, что такое cloudflare, но знаете ли вы, что у них есть очень клёвая услуга для построения бессерверных (serverless) приложений? Воркеры!

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

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

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

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

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

Воркер клаудфлеер для оттдачи кода конвертера

#javascript

#cloudflare

#cloudflare_workers

Конвертер из GitHub Gist в iframe представление

2020-12-30T08:07:36.677Z

Помучился с гистами и телетайпом и решил упростить себе, а заодно и еще кому-то, жизнь - сделать на коленке конвертер.

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

Converter embed code of github gist to iframe

#github_gist

#github

#teletype_in

#tools

Как разместить github gist в постах на платформе Teletype

2020-12-22T08:41:13.597Z

Открыть контекст текстового блока, выбрать iframe.

В контекстном меню выбать iframe

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

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

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

#github

#github_gist

#teletype_in

#блоггерское