gpt4 book ai didi

mysql - 数据适合行时的 VARCHAR 与 TEXT 性能

转载 作者:太空狗 更新时间:2023-10-30 01:45:03 24 4
gpt4 key购买 nike

mysql> desc temp1;
+-------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| value | varchar(255) | YES | | NULL | |
+-------+--------------+------+-----+---------+-------+

mysql> desc temp2;
+-------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------+------+-----+---------+-------+
| value | text | YES | | NULL | |
+-------+------+------+-----+---------+-------+

每行 255 个“a”字符(在两个表中)

mysql> select * from temp1 limit 1;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| value |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

mysql> select * from temp2 limit 1;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| value |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

查询表1:

select count(*) from temp1 where value like '%a';

查询表2:

select count(*) from temp2 where value like '%a';

统计:

No of records---temp1(varchar)---temp2(text)


2097152---------6.08(sec)--------6.91(sec)
4194304---------12.42(sec)-------13.66(sec)
8388608---------25.08(sec)-------28.03(sec)
16777216--------52.82(sec)-------56.88(sec)
33554432--------1(min)50.17(sec)-1(min)59.36(sec)

我的问题:如何解释执行速度的差异?

两个表中的行内容相同。

据我所知,VarCharText 列仅在超过行大小时才将内容保留在页面之外。因此,两个表的内容都将是我的 page size(16kb) 的内联数据。那么这个查询执行时间差的原因是什么。

Note: Both table column is not indexed

Row Format - DYNAMIC

Collation - UTF8mb3

Character set - utf8_general_ci

Storage engine - innodb

Mysql - 5.7

引用链接:https://stackoverflow.com/a/48301727/5431418

更新:相同的流程现在我尝试在两个表中使用 5000 个字符 ('a') 结果差异很大。

2097152---------1(min)53.63(sec)--------2(min)4.66(sec)    

更新 2:相同的流程现在我尝试在两个表中使用 2 个字符 ('a') 仍然存在性能差异

添加表格状态:

mysql> select * FROM information_schema.tables  WHERE table_schema = "db67006db" and table_name = 'temp1';
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME | UPDATE_TIME | CHECK_TIME | TABLE_COLLATION | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT |
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+
| def | db67006db | temp1 | BASE TABLE | InnoDB | 10 | Dynamic | 30625036 | 315 | 9659482112 | 0 | 0 | 425721856 | NULL | 2019-09-23 20:20:17 | NULL | NULL | utf8_general_ci | NULL | | |
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+
1 row in set (0.01 sec)

mysql> select * FROM information_schema.tables WHERE table_schema = "db67006db" and table_name = 'temp2';
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME | UPDATE_TIME | CHECK_TIME | TABLE_COLLATION | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT |
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+
| def | db67006db | temp2 | BASE TABLE | InnoDB | 10 | Dynamic | 30922268 | 315 | 9753853952 | 0 | 0 | 425721856 | NULL | 2019-09-23 20:20:12 | NULL | NULL | utf8_general_ci | NULL | | |
+---------------+--------------+------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------------+

最佳答案

让我们使用一些工具

由于最初的预感(见下文)是错误的,请尝试通过MySQL Workbench 运行您的查询以收集Query Performance Stats .


初步预感(无结果)

只是一个想法:

  • TEXT 磁盘上的列大小为 2 + N 字节,其中 N 是字符串的长度
  • VARCHAR 采用1 + N 字节(对于 N ≤ 255)或 2 + N 字节(对于 256 ≤ N ≤ 65535)

尝试将列中的文本大小扩展到256 个 个字符以上,然后重新运行测试。它们可能会以更接近匹配的性能运行。

另请注意,您发布的差异以每条记录的微秒数表示,因此可能会有许多操作系统事件阻碍或非常简单if (TEXT) {do some additional IO or housekeeping} 源中的代码路径。

关于mysql - 数据适合行时的 VARCHAR 与 TEXT 性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58065891/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com