我的问题的总结是，使用 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 个字符，我会节省大约 …