PostgreSQL单表的列数上限通常只有一两千列，具体取决于数据类型，而超过一万列的CSV文件会让传统建表思路直接失效。勉强把数据拆成多张子表不仅阻碍查询，还会让系统目录急剧膨胀。这类数据往往有一个共同特点：每一行由大量键值对组成，实际查询只关心其中少量列。因此把整行压成一个JSONB文档，再对文档建立GIN索引，就能摆脱列数限制，同时保留按任意列检索的能力。

为什么宽表方案在超万列场景下不可行

PostgreSQL在创建表时会检查列数，超过上限会直接报错。这个上限并不是一个固定值，它受列类型影响，通常在250列到1600列之间。对于一万列以上的CSV，即使拆成七张子表，也需要在查询时进行多次连接，业务代码和SQL复杂度都会明显上升。更麻烦的是，系统目录中每记录一列都要占用额外元数据，宽表会让pg_attribute、pg_class等系统表急剧膨胀。

行存储格式本身就是另一个瓶颈。PostgreSQL的堆元组在物理页中排列，列越多，元组头越大，访问任意一列都需要经过完整的元组定位。对于这种超宽数据，使用JSONB反而更贴近真实使用模型：列名作为键出现，只有实际存在的值才占用空间。加上TOAST机制会自动压缩或外置超过2KB的行，宽行数据的读写性能会相对稳定。

把CSV转换成JSONB的导入流程

最稳妥的导入方式不是让数据库自己解析CSV，而是先用成熟解析库读取文件并生成JSONB。Python的csv模块能正确处理引号、转义和分隔符，psycopg2批量插入效率也足够。下面脚本会读取首行作为列名，之后每行与列名一一配对，转换成JSON字符串后批量写入wide_data表。

import csv
import json
import psycopg2
conn = psycopg2.connect(dbname="wide_db", user="postgres")
cur = conn.cursor()
cur.execute("CREATE TABLE IF NOT EXISTS wide_data(id bigserial PRIMARY KEY, doc jsonb)")
with open('/tmp/wide.csv', newline='', encoding='utf-8') as f:
    reader = csv.reader(f)
    header = next(reader)
    batch = []
    for row in reader:
        if len(row) != len(header):
            raise ValueError("row length mismatch")
        obj = dict(zip(header, row))
        batch.append(json.dumps(obj, ensure_ascii=False))
        if len(batch) >= 1000:
            cur.executemany(
                "INSERT INTO wide_data(doc) VALUES (%s::jsonb)",
                [(item,) for item in batch]
            )
            conn.commit()
            batch = []
    if batch:
        cur.executemany(
            "INSERT INTO wide_data(doc) VALUES (%s::jsonb)",
            [(item,) for item in batch]
        )
        conn.commit()
cur.close()
conn.close()

这段脚本的关键在于使用参数化插入而不是字符串拼接，可以避免引号内容和特殊符号破坏SQL。如果CSV很大，可以按千行分批提交，防止长事务占用过多锁和WAL空间。导入过程中如果遇到列数不一致的行，应该直接终止并报告错误，避免错误数据进入主表。

如果不想写Python，也可以在数据库内使用COPY把文件读入临时表，再用SQL函数拆分。但内置的string_to_array对引号内逗号处理不佳，只适合没有复杂转义的简单CSV。生产环境建议使用Python或其他解析器，先完成严格的CSV解析，再把干净的JSONB写入数据库。

为JSONB建立GIN索引并编写查询

目标表建好后，第一步不是急着查询，而是根据查询模式创建合适的GIN索引。PostgreSQL为jsonb提供了两种内置操作符类：默认的jsonb_ops和更紧凑的jsonb_path_ops。前者支持键存在操作符?、?&、?|和包含操作符@>，后者只支持@>，但索引体积通常小三分之一到一半。

CREATE INDEX idx_wide_doc ON wide_data USING gin (doc);
-- 或者使用 jsonb_path_ops，适合主要用 @> 的场景
CREATE INDEX idx_wide_doc_path ON wide_data USING gin (doc jsonb_path_ops);

如果查询只想判断第3000列是否等于某个值，可以直接写：

SELECT id, doc->>'col_3000' AS value_3000
FROM wide_data
WHERE doc @> '{"col_3000":"目标值"}'::jsonb;

这里的@>是包含操作符，GIN索引可以用它来定位包含指定键和值的行。对于只判断某列是否存在，使用?操作符速度更快，但需要默认的jsonb_ops索引。

SELECT count(*)
FROM wide_data
WHERE doc ? 'col_3000';

值得注意的是，JSONB内部对字符串和数字有严格区分。如果导入时CSV里的数字按字符串保存为"42"，而查询写成@> '{"col_3000":42}'::jsonb，两者不会匹配。要避免这类问题，要么在Python导入时区分类型，要么在查询时保持一致，始终用字符串形式检索。

索引体积与批量导入调优

超万列的JSONB文档单行体积可能超过20KB，GIN索引也会很大。创建索引前建议把maintenance_work_mem调高，减少外部归并排序。对于批量导入，可以临时关闭GIN索引的fastupdate，或者先删除索引、导入后再重建。这样能避免pending list在导入过程中无限增长。

SET maintenance_work_mem = '2GB';
CREATE INDEX idx_wide_doc_path ON wide_data USING gin (doc jsonb_path_ops) WITH (fastupdate = off);

导入结束后要执行ANALYZE wide_data;让统计信息更新。JSONB列的统计信息包含常用键和值分布，但万级键全部统计不现实，少数冷门列可能被规划器低估选择度。如果某个高频查询列总是用@>，可以通过表达式索引单独优化，但不必为万列都建表达式索引。

另外，GIN索引适合包含判断和键存在判断，不适合对JSONB内的数值做范围扫描。如果必须做数值范围查询，应把该列单独提取为普通列或生成列，再建B-tree索引。这是混合策略：频繁查询的少量列提取，不频繁的一律留在JSONB中。

常见问题与备选方案

列名重复是CSV数据的常见问题，JSONB对象会保留最后一个同名键，前面的值被覆盖。导入前应检查header中是否有重复列名，如果业务允许，可自动加后缀改名。缺失字段同样要定义：用空字符串表示缺失会让后续数值比较困难，用null更清晰，但部分查询需要额外处理。

当数据量达到数亿行时，单表JSONB和GIN索引的存储开销会非常可观。这时可以考虑按时间或来源分区，把大表拆小，GIN索引随分区局部创建，查询也能裁剪分区。若查询模式非常固定，只涉及极少数列，更合适的做法是在导入时宽表化只保留这些列，再额外保存一个原始JSONB列兜底，兼顾性能和灵活性。