就像在问题中一样。什么规范应该在数据库中有会话id列。类型，字符集等等。
要求是最快的查询和稳定性，但在从cookie读取会话等过程中的一些优势也会产生重要影响。
好吧我做了些测试。
我使用VARCHAR和CHAR列执行了一个性能测试。这两个列的大小都是64，SID长度都是32字节。在会话的每次刷新时，我插入了一个循环，其中会话不是保存一次，而是重复200次。我使用phpMyAdmin检查了操作的速度，即会话记录和数据库中的顺序。我感兴趣的是：冗余，即数据库中产生的无用空间、索引的大小、行的长度。
结果令人惊讶！
速度不重要，完全一样！如果有时差，两种情况下也完全一样，即：如果某个时间使用VARCHAR在表中的写入过程为500 ms（495-510），则CHAR表中的写入时间完全相同。时间范围从460到510。在两种情况下测试的时间相当。由于存在DDOS攻击的风险，我不会发布指向所检查表的链接。
研究持续了5天，结果表明，冗余取决于被删除的行数，它在这个过程之后立即创建并持续了一段时间。
在两种情况下，它都在4KB和0之间波动。行长度从几百字节，例如600到11 KB。
索引相同，但取决于行数：从4-7 KB和更大的总是从数据。有3个索引的主键和两个其他列。所有相同的类型一个时间戳类型。
然而，这项研究并不完整，它涉及的数据量很小，行数不超过40行，大多数情况下是6-15行，它们经常被随机函数删除。
结论：
在我的情况下，没有什么区别，但正如我所写的，这项研究是基于少量的数据。也许有更多的行，如10000，会有一些区别...
2条答案
按热度按时间ej83mcc01#
uuid或类似的实现被许多平台（如laravel）首选为SessionId，它们使用数据类型作为Varchar（20），需要注意的是，如果您将varchar/string设置为主键，则在使用数据库时可能会导致性能问题。Read More
a11xaf1n2#
Laravel Migration
MySQL中散列函数或uuid的数据类型取决于您希望如何存储和使用它们。
一种选择是对哈希函数和uuid12都使用VARCHAR（36），这允许您将它们存储为人类可读的字符串，但是这可能会占用过多的空间，并影响查询的性能。
另一种选择是对uuid3使用BINARY（16），这样可以将它们存储为原始二进制值，这可能会保存一些空间并提高查询的性能，但也可能会使它们更难读取和操作。
第三种选择是对uuid4使用BIGINT UNSIGNED，这允许您将它们存储为64位无符号整数，这也可以保存一些空间并提高查询性能，但也可能限制可能值的范围并需要一些转换函数。
您对存储和使用会话ID有什么要求？