何时选择 x86-64 还是 aarch64
内容提要
PlanetScale 数据库创建时需在 ARM 与 x86-64 架构间选择，且创建后无法直接切换。ARM 每 vCPU 为完整核心，适合高并发小查询，能效高、性价比好；x86 单核频率更高，支持 AVX2/AVX-512 宽向量指令，适合少量 CPU 密集型查询。两者磁盘文件不兼容，迁移需逻辑复制。默认推荐 ARM，重查询负载可考虑 x86，建议实测后再决定。
延伸解读
架构差异的根源：设计目标不同
x86 起源于桌面，优先考虑向后兼容和性能；ARM 最初为低成本、低功耗设计，其能效优势后来被数据中心看中。这导致两者在服务器上的表现不同：ARM 每 vCPU 是完整核心，适合高并发小查询；x86 单核频率更高，且支持 AVX2/AVX-512 宽向量指令，适合少量 CPU 密集型查询。理解这一背景有助于判断哪种架构更匹配你的负载特征。
向量指令宽度：x86 在特定索引操作上的优势
x86 的 AVX2 支持 256 位向量，AVX-512 支持 512 位，而 AWS Graviton4/5 等 ARM 芯片仅支持 128 位向量。这意味着在 TIN 全文索引中，x86 可用一条 AVX2 指令完成 256 位位图的 AND 操作；pgvector 的 AVX-512 代码也能加速汉明距离和杰卡德距离计算。因此，若工作负载大量依赖这些索引类型，x86 可能带来明显性能优势。
迁移限制：磁盘文件不兼容，需逻辑复制
Postgres 在两种架构上都能运行，但磁盘文件格式不兼容，无法通过物理复制直接迁移。例如 pg_trgm 索引依赖 char 比较，而 x86-64 Linux 默认 char 为有符号，ARM64 Linux 默认无符号，导致同一字节含义不同，索引排序可能不一致。PlanetScale 保持主副本同架构，Neki 中架构在分片配置中固定。若需切换，必须新建集群并通过逻辑复制迁移数据，由目标端重建索引。
选择建议：默认 ARM，重查询考虑 x86，实测为准
对于普通读写应用，ARM 是良好默认选择，性价比高且并行处理能力强；PlanetScale 上同规格 ARM 通常比 x86 略便宜。若少量 CPU 密集型查询主导负载，x86 更合适。最终决策前，建议在相同数据和设置下，分别用 ARM 和 x86 集群测试预期并发，比较吞吐量、慢查询响应时间和成本，再权衡迁移工作量。
Q&A
PlanetScale 数据库创建后可以切换 CPU 架构吗？
不能直接切换。创建集群时必须选择 aarch64 或 x86-64，之后无法更改。如需切换，必须迁移到新集群，使用逻辑复制复制数据并重建索引。
ARM 和 x86-64 在 vCPU 定义上有什么不同？
在 x86 实例上，如果启用超线程，云厂商将每个线程作为一个 vCPU 出售。而 ARM 服务器芯片（如 AWS Graviton 和 Google Axion）不使用超线程，每个 vCPU 都是一个完整的物理核心。
对于高并发小查询的负载，应该选择哪种架构？
推荐 ARM。ARM 的每个 vCPU 是完整核心，核心数更多，适合同时处理大量小查询，例如在线商店中获取商品、检查库存和更新购物车等操作。
x86-64 在哪些场景下比 ARM 更有优势？
当工作负载包含少量 CPU 密集型查询时，x86 更有优势。x86 单核频率更高，且支持 AVX2/AVX-512 宽向量指令，能更快完成单个查询，例如报表仪表板中计算数百万条销售记录的汇总。
为什么 Postgres 数据库文件不能在不同架构间直接复制？
因为不同架构对磁盘文件的解释可能不同。例如，C 语言中 char 的符号性在 x86-64 Linux 上默认为有符号，在 ARM64 Linux 上默认为无符号，导致同一字节含义不同。pg_trgm 索引依赖 char 比较排序，跨架构复制可能导致排序不一致。
如果必须切换架构，应该如何迁移 PlanetScale 数据库？
需要迁移到新集群。在新集群上创建表和索引，然后使用逻辑复制复制行数据并保持同步。目标集群会根据自身比较规则重建索引条目，确保排序正确。
