MySQL Workbench建表需点击绿色「Add Column」按钮提交列定义，否则列名和类型不生效；PostgreSQL推荐TEXT替代VARCHAR(n)以避免长度校验问题；SQLite中NOT NULL列须配DEFAULT值；DBeaver修改列类型需手动执行SQL而非仅保存。
MySQL Workbench 里建表时，列名和类型输不进去？
不是软件卡了，大概率是没点「add column」按钮——界面右上角那个绿色加号。workbench 不像 excel 直接敲，每加一列都得手动触发。输完 column name 和 data type 后，必须点它，否则内容不会进列表，保存时也完全不生效。
常见错误现象：Can't create table 'xxx' (errno: 150) 看似外键问题，实际是某列漏填类型，导致整张表结构解析失败。
- 别在
Column Name栏直接回车，那只是换行，不是提交 -
VARCHAR(255)这类带括号的类型，括号必须英文半角，中文括号会报Unknown data type - 主键列记得勾选
PK，但别多个列同时勾——Multiple primary key defined就来了
PostgreSQL pgAdmin 新建表，TEXT 和 VARCHAR 该怎么选？
选 TEXT 几乎总是更省心。PostgreSQL 内部对 TEXT 和无长度限制的 VARCHAR 存储完全一样，性能没区别；而 VARCHAR(n) 带长度校验，插入超长数据会直接报 value too long for type character varying(n)，调试时容易卡在奇怪的地方。
使用场景：用户昵称、文章摘要、日志内容这类长度不可控的字段，一律用 TEXT；只有明确需约束（比如身份证号固定 18 位），才用 VARCHAR(18)。
-
CHAR(n)在 PostgreSQL 里几乎没优势，补空格行为反而容易引发比对 bug - 时间字段优先选
TIMESTAMP WITHOUT TIME ZONE，除非业务真需要跨时区自动转换 - 布尔字段用
BOOLEAN，别用INT模拟，否则WHERE status = 1在不同方言里兼容性极差
SQLite DB Browser 定义列时，NOT NULL 和 DEFAULT 怎么配合才不翻车？
如果设了 NOT NULL 又没给 DEFAULT，插入时只要该字段没显式提供值，就直接报 NOT NULL constraint failed。SQLite 不像 MySQL 有隐式默认值（比如 0 或空字符串）。
实操建议：所有 NOT NULL 列，要么确保代码里必填，要么配合理默认值。比如状态字段常用 DEFAULT 0，创建时间用 DEFAULT CURRENT_TIMESTAMP。
-
DEFAULT ''和DEFAULT NULL效果相反：NULL会绕过NOT NULL约束，而空字符串不会 - 自增主键写
INTEGER PRIMARY KEY就够，别画蛇添足加AUTOINCREMENT——它额外消耗内存且不提升功能 - 字段名别用
order、group这类 SQL 关键字，哪怕加反引号也容易在 ORM 映射时出问题
DBeaver 新建表后，为什么改了列类型却没生效？
图形界面点「Save」只保存元数据变更，不执行真正的 ALTER TABLE。DBeaver 默认把 DDL 当预览，必须手动点工具栏的「Execute SQL Script」或按 Ctrl+Enter 才真正提交。
容易踩的坑：改完 INT → BIGINT 后点保存，看着界面上变了，但查 PRAGMA table_info(my_table) 还是旧类型——因为根本没发指令给数据库。
- 执行前务必看右下角提示：是「Preview only」还是「Will be executed」
- 修改列类型可能锁表，生产环境避开高峰；SQLite 还不支持直接改类型，得重建表
- 名字含空格或短横线的列（如
user-id），在 DBeaver 里要手动加双引号，否则生成的 SQL 会语法错误
