很多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.
出现在我的屏幕上。¯_(ツ)_/¯
2条答案
按热度按时间p1iqtdky1#
为什么不一直用utf-8呢?拥有ascii表通常是一个错误,一个你忘记设置编码的标志。使用单一编码大大简化了内部架构。
只有当您
CHAR
,VARCHAR
或者TEXT
柱。如果您有一个这种类型的列,那么值得将其设置为
UTF8MB4
默认情况下。xmd2e60i2#
连接ascii和utf-8表会增加开销吗?
对。
如果你这样做了
查询引擎必须比较
id
以及session_id
以满足您的查询。如果
id
以及session_id
如果具有完全相同的数据类型,查询规划器将能够利用索引和快速比较。但是如果它们具有不同的字符集,查询规划器必须按如下方式解释查询。
当where或on条件具有
f(column)
它使查询不可搜索:它阻止了索引的有效使用。这会影响查询性能。在您的情况下,当您将行插入到
session_value
:服务器必须进行转换才能检查外键约束。如果这些表将投入生产,那么您最好对这些列使用相同的字符集。当您有数千行时要比有数百万行时更容易解决这个问题。说真的。
什么使sql语句是可搜索的?