UTF8 与 ASCII 或自定义二进制格式：对非常大的表进行高性能优化

Question

我的问题的总结是，使用 ASCII 或什至是专为这种情况设计的较小格式而不是字符串的 UTF-8 是否有优势，即使是最小的。

可以使用访问数据的网络服务器将一个 ASCII 字符串转换为更紧凑的格式。

在这个问题上，数据库上只有 1-3 个表处理大量数据，因此如果可以放入内存而不是访问磁盘，任何字节都可以产生影响。信息将通过 RESTfull 服务访问

读取与写入：

项目需要更多的读取而不是写入。但是写入有一个特点：每 10 秒就有 40-300 行新行插入到主表中。这些可以并行编写，因为它们不相互依赖。

内存与磁盘使用情况：

最近插入的行，将立即使用，也将插入到缓存中供 Web 服务使用，因此无需再次读取它们。但是对于旧记录的搜索，数据库将需要，并且应该很快。

这就是为什么我认为使用更少的字节来存储某些字段会有所不同：即使对于大量数据，也更容易适应内存。

如果我无法在内存中放入数据，并且数据库无法为我提供某种速度，或者我将需要强制每 10 秒对一个用户进行慢速表/分区扫描，或者我将被迫进行单选并将其缓存在 Web 服务器上，但这打破了 REST 概念中的“无状态”概念。

必须支持的字符

0-9,AZ, "-", "_"。也许需要“az”。只有 38 或 64 个字符，而且永远不会超过这个数。

目前，大多数列是

CHAR(3), CHAR(6), VARCHAR(8), VARCHAR(10).

例子：

使用的技术

数据库将是MariaDB。也许部分 RAW 数据将位于某个NoSQL数据库中。webservice 的语言在这里并没有真正的区别，但将是 PHP 5.4 和框架 Phalcon PHP。

可以使用不同类型的缓存，从 Varnish-cache 到 APC/Mencached，直到缓存在数据库中。

我最初的假设：

一个字段VARCHAR(10)需要 80 位。如果我使用一个自定义表只使用 64 个或更少的字符而不是 255 个字符，我会节省大约 4 次，因此将只使用 20 位而不是 80 位。

Answer 1

您必须支持的字符列表清楚地表明您只需要 plain ascii。

如果您想将其存储为文本，那么这ascii是您最紧凑的方式。但这里有一些澄清：

VARCHAR(10) 不需要“80 位”。它可能需要80位，如果使用了所有的字符，在ascii字符集。如果您只存储 3 个字符（例如'abc'），那么它只需要 24 位。
utf8不会比ascii使用 ascii 字符时存储更多空间。'abc'在两个utf8和ascii编码是3个字节长。这就是它被称为 utf- 8的原因：它尝试在可能的情况下仅使用 8 位。
然而，在临时表（vanilla MySQL；在 Percona Server 上解决；我不确定 MariaDB）上，一个utf8字符无论如何都会占用3个字节；同样的MEMORY表。因此，ascii如果它适合您的需要，最好使用。
你可以进一步压缩。COMPRESS()例如，您可以使用该函数，或通过您自己的方法进行编码（如果您只需要64 个不同的字符，这意味着您使用的是6位。这意味着对于您今天使用的每3个字节（24 位），您可以挤压在另一个字节（使用2次从每个3个字节的击打），因此可以肯定是由25％压缩，甚至更多，但这个留给你。BINARY/VARBINAY类型，这是不容易与工作：你必须总是压缩/解压缩，你将无法索引文本（按字母顺序，也就是说；你当然可以在列上放置索引）。
你提到的其他工具都是无关紧要的；当您的数据到达清漆时，您的文本已解压缩。PHP 也可能如此。