8表会增加开销吗?

x33g5p2x  于 2021-06-18  发布在  Mysql
关注(0)|答案(2)|浏览(401)

很多table都可以用 CHARACTER SET ascii COLLATE ascii_bin 稍微快一点。举个例子:

CREATE TABLE `session` (
    `id` CHAR(64) NOT NULL,
    `created_at` INTEGER NOT NULL,
    `modified_at` INTEGER NOT NULL,
    PRIMARY KEY (`id`),
    CONSTRAINT FOREIGN KEY (`user_id`) REFERENCES `user`(`id`)
) CHARACTER SET ascii COLLATE ascii_bin;

但如果我加入其中:

CREATE TABLE `session_value` (
    `session_id` CHAR(64) NOT NULL,
    `key` VARCHAR(64) NOT NULL,
    `value` TEXT,
    PRIMARY KEY (`session_id`, `key`),
    CONSTRAINT FOREIGN KEY (`session_id`) REFERENCES `session`(`id`) ON DELETE CASCADE
) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

会发生什么?逻辑告诉我它应该是无缝的,因为ascii是utf-8的子集。人性告诉我,我可以期待任何东西,从核心垃圾到信息 Follow the white rabbit. 出现在我的屏幕上。¯_(ツ)_/¯

p1iqtdky

p1iqtdky1#

为什么不一直用utf-8呢?拥有ascii表通常是一个错误,一个你忘记设置编码的标志。使用单一编码大大简化了内部架构。
只有当您 CHAR , VARCHAR 或者 TEXT 柱。
如果您有一个这种类型的列,那么值得将其设置为 UTF8MB4 默认情况下。

xmd2e60i

xmd2e60i2#

连接ascii和utf-8表会增加开销吗?
对。
如果你这样做了

SELECT whatever 
  FROM session s
  JOIN session_value v 
         ON s.id = v.session_id

查询引擎必须比较 id 以及 session_id 以满足您的查询。
如果 id 以及 session_id 如果具有完全相同的数据类型,查询规划器将能够利用索引和快速比较。
但是如果它们具有不同的字符集,查询规划器必须按如下方式解释查询。

...  JOIN session_value v 
         ON CONVERT(s.id USING utf8mb4) = v.session_id

当where或on条件具有 f(column) 它使查询不可搜索:它阻止了索引的有效使用。这会影响查询性能。
在您的情况下,当您将行插入到 session_value :服务器必须进行转换才能检查外键约束。
如果这些表将投入生产,那么您最好对这些列使用相同的字符集。当您有数千行时要比有数百万行时更容易解决这个问题。说真的。
什么使sql语句是可搜索的?

相关问题