非常精准的体现了自己的技术水平

这样还不够，最好字段名称是 str1,str2,...

没啥好处，懒呗

好处就是啥都可以存进去

用 text 吧，var 还有限制 /dog

偷懒了

某些情况下是有点好处, 比如你订单弄成 long, 哪天里面想加点字符就搞不定了.

高性能 MySQL ？

好处没想到，坏处倒是有，举个简单的例子，假设你用 varchar 来存储数字，并且需要排序的时候，会发现排不了

可能是培训班出来的，我们老师当时说 不会选引擎就选 innodb 不会选字段就选 varchar

补充一下坏处，时间也用 varchar 存，那按时间区间查询也不能简单的直接><=between 。
坏处随便想想就有不少，好处除了存数据方便不用脑子反正不会报错，想不出其他的

pg 用 varchar 没问题 ，pg 的 varchar 和 text 几乎一样，都能存大文本

梭哈流建议直接 json

排序需要用 int ，时间用 timestamp ，内容多用 text ，其他用 varchar ，基本够用了。

好处不如别设计了，换 no sql 吧，爱啥字段啥类型就啥

可以多加班

梭哈流直接 json+1 ，懒得设计复杂的数据库表结构，一个 json ，能解决太多问题了，项目里面就喜欢直接存 json ，不设计复杂的表结构。

这边建议直接用 MongoDB

也要看使用场景，某些场景就是可接受的，甚至是推荐的。比如做 ELT 数仓，第一步就是将数据拉取过来，在无法保证上游数据质量的情况下，落地 Staging 层的表就可以全用 varchar ，之后再慢慢清洗。varchar 虽然耗空间，但数据兼容性不错

sqlite 很多类型实际都是用 varchar 存的。

SAP 的大部分字段都是用 CHAR 类型。

归根到底要看实际情况需要。

我也是，但是为什么让我养成了这个习惯，客户改需求导致，做好后这个位置改一下，不要这个换另外一个内容，然后又换，又换，，，，，换了后数据库这边格式没有改过来的话就蹦了，其他的调用了这个的话，又要改，但是改成 var 的话，只需要改前端就好了，反正都适配，一个字 方便

varchar 有长度限制啊，要排序要检索的用匹配需求的类型，其他字段还不如一把梭塞 text 里，改 proto 就行。

可能是从大公司毕业的

然后排序就成了 order by case ，cpu 拉满