MySQL中表注释正确写法是CREATE TABLE或ALTER TABLE语句末尾用COMMENT='内容'，长度上限2048字符，不报错截断，需用SHOW CREATE TABLE或information_schema确认生效。
MySQL 中用 COMMENT 给表加注释的正确写法
直接在建表或修改表时用 comment 关键字，不是字段级注释的延伸，也不是靠额外元数据表维护。mysql 原生支持表级注释，但只在 create table 或 alter table 里生效，且长度上限 2048 字符（5.7+），超长会被截断不报错。
CREATE TABLE t1 (id INT) COMMENT = '用户主表，含注册时间与状态'-
ALTER TABLE t1 COMMENT = '用户主表（含软删除标记）'—— 覆盖原注释，不是追加 - 注释内容不参与 SQL 解析，不能含单引号嵌套，建议用双引号包裹字符串避免 shell 或脚本中出问题
- 执行后查
SHOW CREATE TABLE t1或查information_schema.TABLES的TABLE_COMMENT字段确认是否写入成功
PostgreSQL 怎么给表加注释：必须用 COMMENT ON TABLE
PostgreSQL 不支持建表语句里写表注释，必须单独执行 COMMENT ON TABLE。漏掉这步，哪怕 DDL 看起来完整，注释也不会存在；而且它不支持中文括号、特殊符号时可能被前端工具截断显示为空，实际存进去了。
COMMENT ON TABLE users IS '核心用户信息，含手机号加密存储';- 修改注释要重新执行整条
COMMENT ON TABLE，没有ALTER TABLE ... SET COMMENT这种语法 - 注释会持久化到
pg_description系统表，用SELECT obj_description('users'::regclass)查 - 如果表名带 schema，比如
public.users，COMMENT里也得写全，否则默认找当前search_path下的同名表
注释写什么才真正有用：避开“表结构说明”式废话
业务系统里最常写的“用户信息表”“订单主表”这类描述，对排查问题、理解逻辑几乎没帮助。真正有用的注释要回答“这个表为什么存在”“哪些服务/任务依赖它”“数据生命周期怎么走”。
- 写清楚关键业务约束：例如
'T+1 全量同步至数仓，下游 BI 报表依赖此表 last_modified 字段' - 标注敏感字段处理方式：例如
'身份证号已脱敏，原始值仅存于加密日志，此处为 SHA256 摘要' - 注明非标准行为：例如
'status 字段 99 表示人工冻结，非系统状态机流转结果，需单独监控' - 避免写“创建时间：2023-01-01”，这种信息从 Git 历史或 DDL 变更记录里更准，且容易过期
ORM 框架里怎么让表注释自动同步（以 Django 为例）
Django 的 Meta.db_table_comment 是 4.2+ 新增的，但默认迁移命令不会生成对应 SQL；Flask-SQLAlchemy 或其他 ORM 几乎都不原生支持表注释，得手动干预迁移文件。
- Django：在模型
Meta类里加db_table_comment = "用户登录行为快照，保留 90 天"，然后运行python manage.py makemigrations --empty，再手写operations=[migrations.RunSQL("ALTER TABLE xxx COMMENT = ...")] - SQLAlchemy：没内置支持，可在
create_engine后执行一次engine.execute("COMMENT ON TABLE ...")，但要注意只执行一次，避免重复报错 - 所有 ORM 场景下，别指望
inspectdb或autogenerate能读回注释——它们基本忽略TABLE_COMMENT字段
