blocks|key|1646861|text|这是个好问题。我在很多地方看到他们使用varchar来表示各种看起来像数字的ID。那么为什么不使用整数呢？根据我的经验，主要有三种情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1646862|1646863|虽然它们是数字，但它们可能太大了。例如，您不能将整数(即使是64位大整数)用于32位数字(64位无符号整数的最大值是20位)。|ordered-list-item|1646864|某些数字有特殊的格式。例如，电话号码可能如下所示：%2B44(12)3456789。现在很明显，%2B、(和)不是数字的一部分，您可以在没有它们的情况下调用数字，但这是通常的格式，因此使用整数变量时，您将无法存储此数字。|1646865|将来您可能会将is更改为包含字母，因此最好从头开始允许字母，以避免以后必须更改数百万条记录。|1646866|1646867|希望这能有所帮助。|1646868|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

That's a good question. I have seen in many places that they use varchar for different kinds of IDs that looks like numbers. So why not use integer? Well, in my experience, there are three main cases:

<ol>
<li>Although they are number, they might be too big. For example, you wouldn't be able to use integer (even the 64-bit big integer) for a number with 32 digits (the maximum for 64-bit unsigned integer is 20 digits).</li>
<li>Some number have special formatting. For example, a phone number might look like this: +44(12)3456789. Now obviously, the +, (, and ), are not part of the number and you can call the number without them, but this is the usual format, so with an integer variable, you will not be able to store this.</li>
<li>In the future you might change your IDs to include letters, so it is a good practice to allow letters from the beginning to avoid having to change millions of records later.</li>
</ol>

Hope that helps.

blocks|key|1646796|text|你可能想看看PROCEDURE+ANALYSE。它可以帮助您根据表中已有的内容建议适当的数据类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1646797|这里有一个blog+post，它也谈到了过程分析，可能也会有所帮助。|1646798|entityMap|0|LINK|mutability|MUTABLE|url|http://dev.mysql.com/doc/refman/5.0/en/procedure-analyse.html|1|http://www.mysqlperformanceblog.com/2009/03/23/procedure-analyse/^0|6|H|0|0|5|9|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

You may want to check out <a href="http://dev.mysql.com/doc/refman/5.0/en/procedure-analyse.html" rel="nofollow">PROCEDURE ANALYSE</a>. It can help to suggest the appropriate data types based on what is already in your table.

Here is a <a href="http://www.mysqlperformanceblog.com/2009/03/23/procedure-analyse/" rel="nofollow">blog post</a> that also talks about PROCEDURE ANALYSE and might help as well.

blocks|key|2656829|text|如果您的GUID总是长度为36且不为null，请使用CHAR而不是VARCHAR。它将节省空间，因为VARCHAR必须为每行存储一个长度前缀。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2656830|此外，如果所有列的长度都是固定的，那么在某些情况下会提高性能，因为数据库可以更有效地扫描行。|2656831|MySQL+Reference+Manual+-+The+CHAR+and+VARCHAR+Types|offset|length|2656832|entityMap|0|LINK|mutability|MUTABLE|url|http://dev.mysql.com/doc/refman/5.0/en/char.html^0|0|0|0|1F|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

If your GUIDs are always length 36 and not null, use CHAR instead of VARCHAR. It will save space because VARCHAR must store a length prefix for each row.

Also, if all of your columns are fixed length, it will increase performance in some cases since the database can more efficiently scan rows.

<a href="http://dev.mysql.com/doc/refman/5.0/en/char.html" rel="nofollow">MySQL Reference Manual - The CHAR and VARCHAR Types</a>

blocks|key|1644362|text|这完全取决于你所说的“最合适”是什么意思。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1644363|varchar(36)的优点是简单。您可以按原样存储GUID，并轻松地将其读回。|1644364|但是，如果您担心该列占用的磁盘空间量，那么您有几个选择：|1644365|varchar(+36+)+=+37字节char(36)+=36字节char(+32+)+=32字节(只需去掉连字符)+binary(+16+)+=16字节(去掉连字符并对GUID进行非十六进制以获得二进制字符串)|1644366|因此，如果您担心磁盘空间问题，您会发现binary(16)比varchar(36)要好得多。|1644367|下面是一个从MySQL中的GUID获取二进制(16)字符串的示例：|1644368|unhex(replace(uuid(),'-',''))|code-block|syntax|javascript|1644369|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|Y|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

It all depends on what you mean by "most suitable".

The advantages of varchar(36) is simplicity. You can stored the GUID as is, and read it back easily.

But if you are worried about the amount of disk space that the column takes up, then you have a few choices:

varchar(36) = 37 bytes
char(36) = 36 bytes
char(32) = 32 bytes (just remove the hyphens)
binary(16) = 16 bytes (remove the hyphens and unhex the GUID to get a binary string)

So if you are worried about disk space you will find that binary(16) is much better than varchar(36).

Here's an example of getting a binary(16) string from a GUID in MySQL:

<pre><code>unhex(replace(uuid(),'-',''))
</code></pre>

blocks|key|1646829|text|我的意思是，varchar允许使用每个字符，并且通常可以防止像number数据类型那样溢出。So...well，如果您希望GUID包含较大的值或数字字符之外的值，那么您就大错特错了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1646830|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I mean, varchar allows for every character to be used and is typically prevented from overflow like the number datatypes. So...well, if you expect your GUIDs to contain large values or values outside of numerical characters, then you're golden.

Most of the tables in my db have data of type varchar and length set as 36 used to fill natively created guids. Is varchar the most suitable data type to store guid values or any other type in mysql ? plz explain

mysql datatypes

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我的数据库中的大多数表都有varchar类型和长度设置为36的数据，用于填充本地创建的guids。在mysql中，varchar是最适合存储GUID值的数据类型还是其他类型？请解释一下

问mysql数据类型
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问mysql数据类型EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问mysql数据类型
EN