上面那条回答比较笼统，按我自己用 OBS 的情况，新手容易栽在这几处。 区域一旦选定就不能改。云服务器在哪个区域，桶就建在哪个区域。机器在北京、桶在上海，读写都走公网，又慢又出流量费。网站图片和备份，跟主机放一起。 权限不要开成公共读写。公共读只留给本来就要给别人下载的图片、安装包。公共写等于谁都能往桶里传文件，过几天请求费算在你头上。程序访问就单独建一个子用户，只给这一个桶的权限，主账号的密钥别写进仓库。 删除没那么干净。开了多版本之后，列表里看着空了，历史版本还在，存储费照算。想删桶，先清版本和碎片，再删桶。 文件又碎又多时，费用经常出在请求次数，不是只看出了多少流量。日志、缩略图能合并就合并，别一个小文件一次请求。 拿桶当网站目录，要另外打开静态网站，并把默认首页指到索引页。只把文件传上去，用桶域名打开常常是下载，不是网页。桶要绑自己的域名，域名得先完成备案，不然访问会被拦。

能用，但得分清你进的是哪一种。 页面角落那个开发者空间，点进去有体验版和持久化版。体验版是浏览器里的临时环境，关掉页面会话就没了，里面一般没有能长期用的容器服务，装上去也留不住。 要自己跑容器，选持久化版。那是一台一直在的云主机，进系统后可以自己装容器引擎，镜像会留在磁盘上。装之前先看系统盘还剩多少，镜像一多很容易把盘写满。 别和空间里预置的智能体运行环境搞混。那个是给技能和智能体准备的，不是给你当容器宿主机。自己的网站、数据库，放持久化主机或者轻量服务器上更合适。

刚用对象存储时踩过的几个坑，按我碰到的顺序写。 桶明明开了公共读，外链还是 403。桶策略和对象自己的访问控制是两层。桶策略里如果写了拒绝，你把单个对象改成公共读也没用。先看桶策略有没有显式拒绝，再看这个对象自己的权限。 同区域的云服务器下载，流量费比存储费先出来。默认域名经常走公网。同区域访问要用内网访问域名，桶概览里有，别拿外网域名在服务器上直接拉文件。 对象名里有中文、空格或加号。浏览器里点得开，自己拼的临时链接却 403。签名之前先把对象名编码，签完再拼地址，不要签完又编码一次。 覆盖上传把旧文件冲掉。没有版本控制就找不回来。新手桶建议打开版本控制，同时配生命周期，过几天把非当前版本清掉，不然历史版本会一直占空间。 控制台只列出前面一千条，文件夹看起来是空的。列举默认一页一千，要接着翻下一页，别凭第一页判断桶里没东西。 开了服务端加密，换个子账号就下载失败。勾选加密只是第一步，下载的人还要有对应密钥的使用权限。可以先用开加密的那个账号在控制台下载，确认文件本身是好的，再补子账号的密钥权限。 还有一个费用上的：备份脚本每次全桶列举，请求次数会冒出来。按前缀做增量，别每次从头扫。 帖子正文我这边刷新是加载失败，上面是按标题答的。如果有具体报错码，贴出来可以对得更准。

会回退，但只在8.0之前。 5.7及以前，自增计数器只放在内存里，重启后InnoDB会去表里 select max(id) 再加1作为新的起点。所以如果你把最大的几条记录删了再重启，自增值就会往回退，之前用过的id又会被重新分配出去，有人拿id做外键或日志关联的话会串数据。 8.0开始把自增计数器持久化到redo log里了，重启之后不会再回退，删了最大值也不会重新用。 另外几点我踩过的：1. 8.0里手动 alter table 改auto_increment，设得比当前最大值小是不生效的。2. 就算不重启，insert失败回滚、insert ... on duplicate key update 这些也会让id出现空洞，别指望id连续。3. 如果线上还是5.7，又很依赖id不重复，就别靠自增当业务唯一标识，用雪花id之类的更稳。

简单说就是数据放哪、能不能回收空间的区别。 共享表空间：所有表的数据和索引都塞在ibdata1里，这个文件只会涨不会缩，删了表或数据，空间也还不回操作系统，时间长了ibdata1特别大，很头疼。 独立表空间：每张表一个.ibd文件，在库目录下。drop表、truncate、optimize table之后空间能真正还给磁盘，单表迁移、备份、恢复也方便。 innodb_file_per_table就管这个，5.6以后默认就是ON，所以新建的表一般都是独立表空间。注意两点：1. 改成ON只对之后新建的表生效，老表还留在ibdata1里，要用 alter table 表名 engine=innodb; 重建一下才会搬出来。2. 就算开了，undo日志、数据字典这些还是在系统表空间里，ibdata1不会因为你开了参数就变小。 线上我的建议是一直开着ON，大表碎片多了就找低峰期optimize一下。

补充几个选型时容易忽略的点：1. 版本：MySQL 5.7.7 起默认 binlog_format=ROW，8.0 默认也是 ROW，且 8.0.34 起该参数已标记为弃用，新业务建议直接使用 ROW。2. 下游工具：数据迁移、增量同步、binlog 解析（如 DRS、canal 等）通常要求源库使用 ROW 格式，具体要求请以官方文档为准，因此使用 SBR/MBR 可能无法对接这些工具。3. 日志体积：RBR 在批量更新/删除时 binlog 会变大。可以缩短 binlog 保留时间、控制单事务大小；binlog_row_image=MINIMAL 能减小体积，但部分下游工具要求 FULL，改动前请先确认。4. 查看与修改：SHOW VARIABLES LIKE 'binlog_format'; 可查看当前值，生产环境不建议在业务高峰期修改，修改后新会话才生效。结论：一致性优先选 ROW；只有日志量成为瓶颈且 SQL 全部确定可控时，才考虑 SBR 或 MBR。