暴论

换也不妨去换 SQL Server 或者 PostgreSQL ，MySQL 就没必要了吧

异步了也分一下批，免得把机器带宽打满了，还是要传好久才能传完，先把一部分传好从不所有机器都挤牙膏强

@CEBBCAT BUGINT 可太真实了

@waising with time zone 并不是说数据库会存储输入的 timezone ，这是个比较迷惑的名字，存储的是一个绝对的时间点（实际上存的 UTC ），输入输出时按当前设定时区走

按 PostgreSQL FAQ 里的最佳实践，用 timestamp with time zone ，如果需要时区信息就单独开个字段存 IANA 时区数据库里的时区 ID

@yiplee 可是看 explain 如果我没理解错它走了另一个索引（不太熟悉 MySQL 的 explain 输出

b=?命中的数据太多？

@jezal ICANN 不给吗😰

@jim9606 要是我一定会单开字段，或者弄成一个 json 字段

得···打错了···的是 -> 是的

@janus77 的是，其实一共也没多少

当然，程序内部往往不存在借用类型的需要，这种情况应该创建一个正常的「身份证号」数据类型，我所谓的「借用」更多时候指在 SQL 数据库中，有些数据库不能方便的创建类型别名或者增加自定义类型

@GuuJiang 换一个思考方式会不会好一点：我只是借用了一个 64bit 的数据类型（这个类型很常见）并没有把它当作数值进行计算，实际上这也没有意义；
而所谓的字符串也好，我这种做法也好，实际上都是身份证号的一种编码方式，相对于 144bit 更加节省而已～

@wxf666 还是不行，很多地方不便于使用 无符号数，那么实际上可用的值最大只有 2^63 ，溢出了

@wxf666 视为两位十进制数这点我没想到，我光考虑前面那种了🤣

话说大家真的有遇到过身份证号模糊匹配的需求吗，这点有些好奇，我确实没见过…

@oneisall8955 @IvanLi127 如果是字符串正则查找，那确实是不行了，不过我没见过这种场景；允许存错误的身份证号这就没办法了🤣除非在一开始明确提出我不会考虑这种需求

@wxf666 可以是可以，主要会不直观，如果只是简单去掉最后一位，不影响以十进制方式阅读

@janus77 主要是便于用数值而非字符串类型存储，19+字节变成定长 8 字节吧，我觉得对于某些量大的场景还是很划算的。

@eason1874 只有在系统边界将身份证号类型装换成字符串类型传输的时候才需要计算和补足最后一个校验码，校验算法非常简单，所以应该不会消耗过多的 CPU

tab all 也不是时间排序啊