在SQL中存储多个不同尺寸3D数组的最优方案是什么？

方案评估结论 #

如果严格在你列出的3个方案中做选择，优先级为 方案2 > 方案3 > 方案1，结合你「全量读取、只读不修改」的使用场景，还有远优于三个方案的实现方式。

各方案详细分析 #

• 方案1（每个数组对应一张表）：完全不推荐
  该模式完全违背关系型数据库设计逻辑，当数组数量增长到上百上千时，表数量会极度膨胀，运维、备份、查询的成本都会指数级上升，查询时需要动态拼接表名还会带来SQL注入风险。
• 方案2（每种尺寸对应一张表）：固定尺寸场景下最优
  优势：单表数据量可控，索引仅需建在ID字段即可，查询不需要额外过滤尺寸条件，性能最好。如果你的数组尺寸长期只有固定的3-5种，该方案是三个选项里效率最高的。
  劣势：后续新增尺寸需要手动建表，代码中需要维护尺寸到表名的映射逻辑，扩展性较差。
• 方案3（统一大表存储）：多可变尺寸场景下最优
  优势：扩展性最强，新增任意尺寸都不需要调整表结构，代码逻辑统一不需要做表名映射，适合尺寸类型多、未来可能新增尺寸的场景。
  劣势：需要建立size + ID的联合索引，索引存储开销略高于方案2，单表数据量超过千万级后，查询性能会比方案2略有下降。

适配你场景的最优方案 #

你明确提到数组每次都是全量取出、写入后不会做任何修改，完全不需要按x/y/z坐标做单条查询，根本没必要把每个坐标点拆为单独的行存储，更推荐你用单条记录存整个数组的方案：
建一张统一的数组存储表，字段设计为(ID, size, array_data, create_time)，其中array_data用BLOB或者JSON类型存储整个数组序列化后的结果。
一个50x50x200的数组序列化后也只有几百KB到几MB（取决于元素数据类型），单次查询仅需取回一条记录就能拿到完整数组，IO开销比查询几十万行坐标点低几个数量级，开发和维护成本也是最低的。

内容的提问来源于stack exchange，提问作者Joe Moore