MySQL表注释修改后不生效是因查询方式错误，ALTER TABLE COMMENT已落盘，应查information_schema.tables的table_comment字段而非DESCRIBE；PostgreSQL需用obj_description('t'::regclass,'pg_class')查表注释。
MySQL 表注释修改后不生效，ALTER TABLE ... COMMENT 没报错但查不到
不是没保存，是注释写到了表结构元数据里，但你查的方式不对。默认 show create table 会显示注释，但 describe 或 show columns 不会。
- 确认是否真没生效：用
SELECT table_comment FROM information_schema.tables WHERE table_name = 'your_table' AND table_schema = 'your_db'; - 字段注释同理：查
information_schema.columns的column_comment字段，别只看DESC - 注意字符集：如果数据库/表用的是
utf8mb4，但客户端连接用utf8（实际是utf8mb3），中文注释可能被截断或乱码存入，表现为“空注释” -
ALTER TABLE t COMMENT = '测试'是 DDL，执行成功即已落盘，不存在“未保存”——只是你没查对地方
PostgreSQL 中 COMMENT ON TABLE 执行成功却查不到注释
PostgreSQL 注释存在 pg_description 系统表，但必须指定正确的 objoid 和 classoid，否则 obj_description() 返回空。
- 查表注释正确姿势：
SELECT obj_description('your_table'::regclass, 'pg_class');—— 必须用::regclass转类型，不能直接传字符串 - 字段注释要连表名一起查：
SELECT col_description('your_table'::regclass, 1);（1 是字段序号），或更稳妥地用SELECT description FROM pg_description WHERE objoid = 'your_table'::regclass AND objsubid = 2;（2 是第 2 列） - 权限限制：普通用户只能看到自己有
USAGE权限的 schema 下的对象注释；跨 schema 时，即使注释存在也返回NULL - 事务内执行
COMMENT后未COMMIT，其他会话不可见——这常被当成“没保存”
执行注释语句时报错 Access denied; you need (at least one of) the SUPER privilege(s)
不是所有 MySQL 版本都要求 SUPER，但 5.7+ 默认开启 sql_require_primary_key 或启用严格模式时，某些 DDL 会被误判为高危操作；更常见的是账号权限不足。
- 检查账号实际权限：
SHOW GRANTS FOR CURRENT_USER;，确认包含ALTER和INDEX（MySQL 8.0+ 还需INSERT权限才能写mysql.innodb_table_stats，间接影响部分元数据操作） - 如果是 RDS 或云数据库（如阿里云 PolarDB、腾讯云 CDB），注释功能可能被管控策略禁用，
COMMENT语句会被静默忽略或报权限错，此时需提工单开通 - 避免用
root@localhost以外账号执行，尤其在容器或 CI 环境中——host匹配不精确会导致权限判定失败
注释写错了想回滚，但没开 binlog 或没备份怎么办
注释本身不改数据，也不进 undo log，所以无法靠事务回滚。唯一办法是重写一次正确注释，前提是记得旧内容。
- 先抢救现有注释：
SELECT table_comment FROM information_schema.tables WHERE ...立即查出来存好，这是最后机会 - 如果已覆盖，且没有历史 DDL 记录（比如没开 general_log、没用 Flyway/Liquibase），那就真的没了——注释不是数据，不会被 mysqldump 自动导出，除非你显式加了
--skip-comments以外的选项 - 预防建议：把注释变更纳入版本化 SQL 文件管理，和建表语句放一起；用
pt-online-schema-change或gh-ost时注意它们默认不复制注释，得手动补
事情说清了就结束。注释不是数据，它不参与事务、不触发复制、不进备份快照——它只是元数据里的一个字符串，查不到往往是因为查错了位置，而不是没存进去。
