既然varchar时变长类型，我每次建表时都把varchar设置为varchar65535起不是省心了？

写起来省事了，可是这是浪费存储和性能为大家换来的。实际上你可以用 ntext 可变长度字符串，更好

不知道你这个问题是否已经解决, 如果还没有解决的话:

你可以参考下这个问题的回答, 看看是否对你有帮助, 链接: https://ask.csdn.net/questions/7454452
我还给你找了一篇非常好的博客，你可以看看是否有帮助，链接：数据库 varchar 类型应该设计多长？
除此之外, 这篇博客: 细说varchar与char有哪些区别？中的 3、存储容量 部分也许能够解决你的问题, 你可以仔细阅读以下内容或者直接跳转源博客中阅读:
- CHAR
对于char类型来说，最多只能存放的字符个数为255，和编码无关，任何编码最大容量都是255。
- VARCHAR
MySQL行默认最大65535字节，是所有列共享（相加）的，所以VARCHAR的最大值受此限制。
表中只有单列字段情况下，varchar一般最多能存放(65535 - 3)个字节，varchar的最大有效长度通过最大行数据长度和使用的字符集来确定，通常的最大长度是65532个字符（当字符串中的字符都只占1个字节时，能达到65532个字符）；
为什么是65532个字符？算法如下（有余数时向下取整）：
最大长度(字符数) = （行存储最大字节数 - NULL标识列占用字节数 - 长度标识字节数） / 字符集单字符最大字节数
- NULL标识列占用字节数：允许NULL时，占一字节
- 长度标识字节数：记录长度的标识，长度小于等于255（2⁸）时，占1字节；小于65535时（2¹⁶）,占2字节
VARCHAR类型在4.1和5.0版本发生了很大的变化，使得情况更加复杂。从MySQL 4.1开始，每个字符串列可以定义自己的字符集和排序规则。这些东西会很大程度上影响性能。
- 4.0版本及以下，MySQL中varchar长度是按字节展示，如varchar(20)，指的是20字节；
- 5.0版本及以上，MySQL中varchar长度是按字符展示。如varchar(20)，指的是20字符。
当然，行总长度还是65535字节，而字符和字节的换算，则与编码方式有关，不同的字符所占的字节是不同的。编码划分如下：
GBK编码：
一个英文字符占一个字节，中文2字节，单字符最大可占用2个字节。
UTF-8编码：
一个英文字符占一个字节，中文3字节，单字符最大可占用3个字节。
utf8mb4编码：
一个英文字符占一个字节，中文3字节，单字符最大占4个字节（如emoji表情4字节）。
假设当前还有6字节可以存放字符，按单字符占用最大字节数来算，可以存放3个GBK、或2个utf8、或1个utf8mb4。
以下回答来自chatgpt:
根据参考资料所述，每次建表时将varchar设置为varchar(65535)并非是一个可行的做法，会带来潜在问题。下面是解决方案：
1. 段落0、4、5所述的问题：varchar长度小于等于255时，长度标识位需要一个字节，超过255需要两个字节，并且建立的索引也会失效。因此，在建表时需要根据实际情况选择合适的varchar长度，而不是全部设置为65535。
2. 段落1所述的问题：如果需要插入较大的长文本，可以将字段类型改为text或longtext。
3. 段落2所述的问题：varchar(20)是存储手机号的最佳长度选择，超过20个字符长度会浪费空间。
4. 段落3所述的问题：varchar(50)中50代表字符数，而不是字节数。在排序时，较大的varchar长度会消耗更多内存，因为order by col采用fixed_length计算col长度。
5. 段落6所述的问题：VARCHAR适合存储较长的字符串，而CHAR适合存储较短的字符串或定长的值。如果字符串列的最大长度比平均长度大很多，使用VARCHAR是合适的。
6. 段落7所述的问题：修改VARCHAR大小的时候可以使用在线DDL操作，以避免锁定表。
综上所述，每次建表时将varchar设置为varchar(65535)并不是一个好的做法。应该根据实际情况选择合适的varchar长度，并在需要插入较大的长文本时，将字段类型改为text或longtext。此外，需要合理选择CHAR和VARCHAR的存储方式，并使用在线DDL操作以避免锁定表。

如果你已经解决了该问题, 非常希望你能够分享一下解决方案, 写成博客, 将相关链接放在评论区, 以帮助更多的人 ^-^

会浪费很多存储空间。建议在创建表时，根据实际情况，设置每个字段合适的长度