phpMyAdmin修改列类型为UNSIGNED需在结构页点击更改，类型必须选“INT UNSIGNED”等完整形式，不可仅加关键字；否则ALTER语句不生效，导致值截断或报错#1075。
phpMyAdmin 修改列类型为 UNSIGNED 的实际操作路径
直接在 phpmyadmin 界面改列属性，不是点两下就能生效的——它本质是执行一条 alter table ... modify column（或 change column）语句，而 unsigned 属于类型修饰符，必须连同数据类型一起重写，不能只加个关键字。
常见错误现象：#1075 – Incorrect table definition; there can be only one auto-increment column and it must be defined as a key，或者改完没报错但值还是被截断，说明字段没真正变成 UNSIGNED。
- 进入对应数据库 → 表 → «结构» 标签页
- 找到目标列，点击右侧的
更改（铅笔图标） - 在 «类型» 下拉框里，**不要选
INT，要选INT UNSIGNED**（注意：不同 phpMyAdmin 版本下拉项名称略有差异，有的叫INT(10) UNSIGNED，有的把UNSIGNED单独列为复选框，但新版普遍已合并） - 如果该列是
AUTO_INCREMENT，确保主键约束仍存在（UNSIGNED+AUTO_INCREMENT必须搭配索引，否则会报错）
为什么改了类型却仍然存不下 2147483648？
根本原因：MySQL 的 INT 默认有符号，范围是 -2147483648 到 2147483647；改成 INT UNSIGNED 后上限才变成 4294967295。但如果你只改了显示类型、没提交变更，或 phpMyAdmin 后台生成的 SQL 漏掉了 UNSIGNED，那字段实际没变。
检查是否生效最简单的方法：
在 «SQL» 标签页执行：SHOW COLUMNS FROM `your_table` LIKE 'your_column';，看 Type 列是否显示 int(11) unsigned（或类似含 unsigned 的字样）。
- 如果显示仍是
int(11)，说明修改未成功，可能是因为字段上有默认值、触发器、外键约束干扰了ALTER语句 - 如果字段当前有负数，强行转
UNSIGNED会失败（MySQL 会拒绝），需先清空或修正数据 -
TINYINT/SMALLINT/MEDIUMINT同理，都必须显式写成TINYINT UNSIGNED等，不能只改数值范围
用 SQL 手动执行更可靠，但要注意这些细节
图形界面有时隐藏了底层逻辑，手动写 ALTER TABLE 能看清每一步。不过 phpMyAdmin 对 SQL 的解析较严格，某些写法会报语法错误。
立即学习“PHP免费学习笔记（深入）”；
正确示例（安全可复制）：
ALTER TABLE `users` MODIFY `id` INT UNSIGNED AUTO_INCREMENT;
- 用
MODIFY COLUMN比CHANGE COLUMN更稳妥，后者要求重写列名，稍不注意就误删数据 - 如果列名含特殊字符（如反引号、空格），务必用反引号包裹：
`user_id` - 若字段有默认值，需一并带上：
DEFAULT 0，否则默认值会被清空 - phpMyAdmin 8.0+ 对
ALTER的权限校验更严，确保当前用户有ALTER权限，否则只提示「无法执行」，不给具体原因
改完之后值突然变 0 或乱码？这是数据兼容性问题
不是界面 bug，是 MySQL 在转换时对已有数据做了隐式处理：当原字段存了负数，又强制转成 UNSIGNED，MySQL 会把它解释为补码对应的正整数（比如 -1 变成 4294967295），而 phpMyAdmin 展示层可能直接显示为 0 或截断。
- 改之前务必确认该列**当前没有负值**：
SELECT * FROM `table` WHERE `col` - 如果业务上确实允许负值，
UNSIGNED就不该加——这不是“扩容”万能解，而是语义变更 -
INT UNSIGNED和应用层 PHP 的int类型无强制映射，PHP 读出来仍是普通整数，但超过PHP_INT_MAX（通常 2147483647）时可能被转成 float，引发精度丢失
真正卡住人的地方，往往不是怎么点按钮，而是没意识到：加 UNSIGNED 是改数据语义，不是调参数；它影响存储、校验、索引行为，还牵扯到 ORM 映射和前端传值逻辑。改之前，先查数据、看依赖、试 SQL。
