聊到数据库，很多人第一反应是表、索引、事务这些大词儿。但真到写SQL的时候，天天打交道的其实是列（column）。你可能觉得列不就是字段嘛，建表时写个名字、定个类型就完事了。真这么想，坑就来了。我见过太多线上事故，不是索引没建，而是列的定义从一开始就埋了雷。今天不聊虚的，直接从列的定义讲起，一路讲到实战里那些让人挠头的用法。
先看定义这步。很多人建表像写填空题，类型选个varchar(255)万能，然后就不管了。实际上，列的定义里藏着三样东西：类型、约束、默认值。类型决定存储和比较的方式，比如int和varchar在索引上的表现天差地别；约束管的是数据合法性，NOT NULL、UNIQUE这些不是装饰品；默认值则是在插入时没给值的情况下兜底的。举个例子，你给用户表加个createdat列，类型用datetime还是timestamp？前者占5个字节但范围广，后者占4个字节且自带时区转换，但2038年就溢出了。选错类型，后面要么爆表，要么数据错乱。
再说说命名这回事。列名看着不起眼，但坑起人来一点不含糊。有人喜欢用关键字当列名，比如order、group、desc，写SQL时就得满屏加反引号，丑陋不说，换个工具连SQL都解析不了。还有人用驼峰命名，在MySQL里大小写敏感，在Oracle里又不敏感，跨库迁移时直接抓瞎。我自己的习惯是：小写字母加下划线，比如username、createdat，全小写，永远不用保留字。这样不管在哪个数据库里跑，都不用担心解析问题。
接下来是类型选择的实战细节。整数类型里，TINYINT、SMALLINT、BIGINT，很多人懒得想，直接INT。但你要是存状态码，0到255就够，用TINYINT能省3个字节，一张千万行的表就能省30MB，索引还能更紧凑。字符串类型更是重灾区，varchar要指定长度，这个长度不是随便定的，它影响的是最大字节数，不是字符数。比如varchar(255)在utf8mb4下最多存255个字符，但占的字节数可能到1020。如果你存的是URL，动辄几百字符，定255就等着超限报错吧。更隐蔽的是，varchar长度过长，MySQL在内存里排序时用的临时表会变大，性能直线下降。
再说默认值和空值。很多人建列时默认允许NULL，觉得省事。但NULL在SQL里是个大坑：三个值逻辑（TRUE、FALSE、UNKNOWN）里，NULL就是UNKNOWN，你拿NULL去比较、去聚合，结果全变样。比如COUNT(column)不会统计NULL值，但COUNT(*)会；WHERE column = NULL永远查不到东西，得用IS NULL。所以能设NOT NULL就绝不放手，实在要留空，给个明确的默认值，比如空字符串或者0。这样查询时少一堆脑壳疼的边界判断。
列的位置和顺序，看起来无关紧要，实则影响性能。MySQL里，行数据是紧凑存储的，列的顺序决定了每行的物理布局。你把变长字段（varchar、text）放在定长字段前面，会导致行内偏移量计算变复杂，而且当变长字段更新变大时，可能触发行迁移，产生碎片。更实际的影响是索引：如果你有个复合索引(a, b, c)，查询时如果只用到b和c，索引就废了。所以建列顺序时，得想着查询模式——高频等值查询的列放前面，范围查询的列放后面，这样索引利用率能提一大截。
实战里还有个高频操作：加列。ALTER TABLE ADD COLUMN看似简单，但线上大表直接加列，会锁表，业务直接卡死。MySQL 5.6之前，加列要重建表，几千万行的表能锁半小时；5.6以后有InnoDB Online DDL，但也不是所有操作都支持原地执行。你加个带默认值的列，如果默认值是常量，可以瞬时完成；但如果是表达式或者函数，就得拷数据了。所以加列前先查一下版本和DDL算法，别上来就执行。还有，加列时如果表已经很大，建议用gh-ost或者pt-online-schema-change这类工具，在从库上做变更再切换，零停机。
改列类型和改名，风险更大。改类型意味着要转换存储格式，如果数据不兼容，直接报错，比如把varchar改成int，里面有非数字字符就废了。改名则会让所有依赖这个列的视图、存储过程、ORM映射全部失效。我遇到过最惨的一次，开发把userid改成uid，结果报表系统里十几个SQL还引用旧列名，跑出来全是NULL，数据对不上账，排查了一整天。所以改列前，先跑一遍全库的代码搜索，把引用点全找出来，再动手。
说一个容易被忽略的：列的注释和文档。很多人建完表就扔了，列的业务含义全靠猜。举个真实例子，某系统有个列叫flag，值有0、1、2、3，没人知道啥意思，后来查代码才知道0是未处理、1是处理中、2是成功、3是失败。但代码里还有4和5，文档没写，新同事只能靠猜。所以建列时，注释必须写清楚：字段含义、取值范围、是否可空、默认值逻辑。这不算多余，是给自己和后来人省时间。
回到标题，列字段的用法，表面上是语法问题，深了其实是数据建模和工程习惯的问题。从定义时的类型选择、约束设置，到实战中的加列、改列、查询优化，每一步都藏着细节。别小看这一列一列的，它们拼起来就是整个业务的数据骨架。骨架歪了，后面再牛的查询优化也是白搭。所以下次建表前，多花五分钟想清楚每一列的类型、约束、顺序和注释，后面能省下好几个小时排查问题的时间。
