在 MySQL 中为现有数据生成 GUID?
我刚刚将一堆数据导入到 MySQL 表中,并且有一列“GUID”,我想用新的且唯一的随机 GUID 基本上填充所有现有行。
我如何在 MySQL 中执行此操作?
我尝试过
UPDATE db.tablename
SET columnID = UUID()
where columnID is not null
,只是让每个字段都相同
I've just imported a bunch of data to a MySQL table and I have a column "GUID" that I want to basically fill down all existing rows with new and unique random GUID's.
How do I do this in MySQL ?
I tried
UPDATE db.tablename
SET columnID = UUID()
where columnID is not null
And just get every field the same
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(12)
我需要在现有表中添加一个 guid 主键列,并用唯一的 GUID 填充它,这个带有内部选择的更新查询对我有用:
很简单:-)
I had a need to add a guid primary key column in an existing table and populate it with unique GUID's and this update query with inner select worked for me:
So simple :-)
我不确定这是否是最简单的方法,但它确实有效。我们的想法是创建一个为您完成所有工作的触发器,然后执行更新表的查询,最后删除此触发器:
然后执行
And
DROP TRIGGER beforeYourTableUpdate
;更新
另一种解决方案不使用触发器,但需要主键或唯一索引:
再次更新:
看来您的原始查询也应该有效(也许您不需要
WHERE columnID is not null
,因此不需要我所有的花哨代码。I'm not sure if it's the easiest way, but it works. The idea is to create a trigger that does all work for you, then, to execute a query that updates your table, and finally to drop this trigger:
Then execute
And
DROP TRIGGER beforeYourTableUpdate
;UPDATE
Another solution that doesn't use triggers, but requires primary key or unique index :
UPDATE once again:
It seems that your original query should also work (maybe you don't need
WHERE columnID is not null
, so all my fancy code is not needed.批准的解决方案确实创建了唯一的 ID,但乍一看它们看起来相同,只有前几个字符不同。
如果您想要明显不同的密钥,请尝试以下操作:
我正在使用 MySQL 服务器版本:5.5.40-0+wheezy1 (Debian)
The approved solution does create unique IDs but on first glance they look identical, only the first few characters differ.
If you want visibly different keys, try this:
I'm using MySQL Server version: 5.5.40-0+wheezy1 (Debian)
只是做了一个小小的补充,因为当我尝试修改生成的 UUID 时,最终得到了一个奇怪的结果。我找到了 答案,作者是 Rakesh 是最简单的,效果很好,除非你想去掉破折号。
仅供参考:
这本身就非常有效。但是当我尝试这样做时:
然后所有结果值都是相同的(没有细微的不同 - 我使用
GROUP BY some_field
查询进行了四次检查)。不管我如何放置括号,都会发生同样的事情。似乎当围绕子查询使用 REPLACE 生成 UUID 时,它只运行 UUID 查询一次,这对于比我聪明得多的开发人员来说可能是一种优化,但对我来说却没有。
为了解决这个问题,我只是将其分为两个查询:
显然,简单的解决方案,但希望这会节省我刚刚失去的时间。
Just a minor addition to make as I ended up with a weird result when trying to modify the UUIDs as they were generated. I found the answer by Rakesh to be the simplest that worked well, except in cases where you want to strip the dashes.
For reference:
This worked perfectly on its own. But when I tried this:
Then all the resulting values were the same (not subtly different - I quadruple checked with a
GROUP BY some_field
query). Doesn't matter how I situated the parentheses, the same thing happens.It seems when surrounding the subquery to generate a UUID with REPLACE, it only runs the UUID query once, which probably makes perfect sense as an optimization to much smarter developers than I, but it didn't to me.
To resolve this, I just split it into two queries:
Simple solution, obviously, but hopefully this will save someone the time that I just lost.
MYsql
甲骨文
SQLSERVER
MYsql
oracle
SQLSERVER
看起来像是一个简单的错字。您不是说“...其中columnId 为 null”吗?
Looks like a simple typo. Didn't you mean "...where columnId is null"?
我遇到了几乎同样的问题。
我的情况下 uuid 存储为 BINARY(16) 并且具有 NOT NULL UNIQUE 约束。
当为每一行生成相同的 UUID 时,我遇到了问题,并且 UNIQUE 约束不允许这样做。所以这个查询不起作用:
UNHEX(REPLACE(uuid(), '-', ''))
但对我来说它有效,当我使用嵌套内部选择这样的查询时:
UNHEX(REPLACE((SELECT uuid()), '-', ''))
然后为每个条目生成唯一的结果。
I faced mostly the same issue.
Im my case uuid is stored as BINARY(16) and has NOT NULL UNIQUE constraints.
And i faced with the issue when the same UUID was generated for every row, and UNIQUE constraint does not allow this. So this query does not work:
UNHEX(REPLACE(uuid(), '-', ''))
But for me it worked, when i used such a query with nested inner select:
UNHEX(REPLACE((SELECT uuid()), '-', ''))
Then is produced unique result for every entry.
我这样做了:
SELECT
五个小写字符,五个大写字符和一个特殊字符。I did this:
SELECT
five characters in lower case, five characters in upper case and one special character.当使用 mysql 作为 sql_mode = "" 时出现此错误。经过一番测试,我确定问题是由这种用法引起的。当我在默认设置下测试时,发现不存在这个问题。
注意:更改模式后不要忘记刷新连接。
I got this error when using mysql as sql_mode = "". After some testing, I decided that the problem was caused by this usage. When I tested on the default settings, I found that this problem was not there.
Note: Don't forget to refresh your connection after changing the mode.