偷懒导致的 mysql 类型转换的问题

[yqmac]

背景：接手了别人的代码，id 用的 varchar 但是内容是拼接出来的时间戳，都是长整型。

蓝后，写个 select 语句，偷懒，一直懒得加单引号 突然发现一个 select 出来了 6 条，卧槽，大问题，id 生成策略会重复。 面对重型生产问题，一步步查，怎么都觉得不会重复，一看，卧槽，这六条 id 不一致啊。 …… 当当当当~ select 661843814642404550000000 = '661843814642404556823288' 得到 1 突然惊醒 mysql 数据转换有问题，一查文档，果然，丢精度。所以，偷懒没好处……各位引以为戒。

[tedderchan]

第一次听说有人 id 用 varchar, 我我也是醉了

[KasuganoSoras]

第一次听说有人 id 用 varchar

[walpurgis]

看见弱类型语言出现大数字要警惕，上次碰到前端 js 接收的 JSON 里有个 20 位数字，末尾都是 0，同样的问题

[CStarter]

@tedderchan id 用 uuid，就是 varchar 啊

[sx90]

id，不是表格内部自增号吗🤣

[opengps]

id 用 varchar 不是问题，uuid 就用 varchar 存储。不正常的是类型不严格

[luozic]

丢精度这是 feature ？；类型系统这个东西有一本非常厚的书，一般用的语言类型系统都是半生不熟，sql 这东西设计里面就没有非常严格的类型系统玩。

[msg7086]

@Tranvin @opengps
UUID 严格来说应该是 BINARY(16)，就算用文本存储也不是 VARCHAR 而是 CHAR(36)或者 CHAR(32)。

[guanhui07]

第一次听说有人 id 用 varchar

[opengps]

我要是在本帖回一句，我最自豪的数据库设计是无主键，是不是会被鄙视😃😄😁😀

[ZredoC]

图怎么莫得了

[ytll21]

@opengps 把你的故事说出来 :P

[opengps]

@ytll21 之前分享过连接，主要核心就一个：匹配业务。
用于传感器采集类业务的巨型表设计（关系型数据库版）： https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex

[lskjdfgl]

抓紧看了下我的数据库设计，现在改也不知道来不来的及😂

[qq1054000800]

innode 引擎，用 uuid 做主键是非常糟糕的设计

[yqmac]

说实话，系统我是个接盘侠，主键 uuid 或者这种长整型的 varchar 也是恨不能理解的……但是这个玩意已经无法更改了啊，前人挖坑后人……，难道自增不香么。