# 以下配置从 /etc/filetype/config.json 中加载 CREATE INDEX...

创建于:2025年5月28日

使用 O3 回答 Chat01

问题

以下配置从 /etc/filetype/config.json 中加载

CREATE INDEX %s.%s_video ON %s(suffix) WHERE suffix IN ('mp4','avi','mkv','mov','wmv','flv','webm','m4v','3gp','3gp2','mpeg','mpg','ts','m2ts','mts','tp','trp','vob','ogv','ogm','divx','rm','rmvb','asf','qt','f4v','swf','h264','h265','hevc','vp8','vp9','av1','dat','avs');
CREATE INDEX %s.%s_photo ON %s(suffix) WHERE suffix IN ('jpg','jpeg','png','gif','bmp','webp','tiff','tif','heic','heif','avif','svg','ico','pcx','pict','psd','psp','thm','yuv','ai','indd','eps','jp2','j2k','jpf','jpx','jxl','jpm','mj2','raw','cr2','cr3','nef','arw','dng','orf','rw2','pef','srw','raf','mrw','x3f','nrw','dcr','kdc','3fr','mef','erf','srw','iiq');
CREATE INDEX %s.%s_document ON %s(suffix) WHERE suffix IN ('pdf','doc','docx','xls','xlsx','ppt','pptx','txt','csv','rtf','odt','ods','odp','odg','odf','sxw','sxc','sxi','wpd','tex','md','markdown','pages','numbers','key','html','htm','xhtml','xml','json','yaml','yml','log','ini','conf','cfg','dotx','wps','wpt','xltx','pot','potx','ppsx');
CREATE INDEX %s.%s_audio ON %s(suffix) WHERE suffix IN ('mp3','wav','ogg','flac','aac','m4a','wma','alac','ape','aiff','au','mid','midi','amr','ac3','dts','ra','ram','3ga','opus','aif','aifc','caf','dsf','dff');
CREATE INDEX %s.%s_archive ON %s(suffix) WHERE suffix IN ('zip','rar','7z','tar.gz');
要这样建索引吗?如果索引变动的时候,要改数据库吗?

思考

Answering SQL-related question

The user is asking about the correctness of creating indexes and whether changes in index definitions require a database alteration. Partial indexes based on suffix seem sensible for categorizing different file types. They can improve performance if you query based on suffix often, especially with large datasets. If the index definition changes later, the change only impacts the index itself, not the entire database structure, though you might need to recreate the affected indexes.

Discussing index strategies and database changes

It seems the user is looking into index creation strategies, specifically whether to use individual partial indexes or a single generalized one, and how index definitions may need to change if data changes. In this case, if index definitions are altered (e.g., adding or removing suffixes), the index must be dropped and recreated or modified. Index design guidelines suggest using only those columns relevant to queries, monitoring index usage, and maintaining up-to-date statistics. A simpler expression index may be more efficient, or even a multi-column index for high-cardinality queries.

Thought for 24 seconds

回答

下面从「可行性」「维护成本」「变动时的操作」三方面来回答。


1. 这样建索引可行吗?

方案适用场景优点缺点
单列完整索引<br>CREATE INDEX idx_suffix ON files(suffix);查询经常直接 WHERE suffix = 'mp4'IN (...),且写入量较大・只有一个索引,维护简单<br>・适配所有后缀・扫描范围比部分索引大,若写入多读少浪费 I/O
分类型「部分索引」(你现在的写法)查询经常带固定分类条件<br>...WHERE suffix IN ('mp4','avi',...)・每个索引只包含该分类行数,读性能好<br>・可以并行/分步创建或删除・需要维护多条索引 DDL<br>・写入时会多次检查谓词,写放大
计算列 + 单列索引<br>先新增 file_type 虚拟列(Video/Photo…),再对 file_type 建普通索引后缀种类经常增删改,分类逻辑清晰・索引谓词稳定,只改计算列逻辑即可<br>・扩展/调整新后缀不用改索引・需要额外列或表达式索引支持

总结:如果

  • 查询读多写少,且每次都带类别过滤 —— 继续用 部分索引
  • 后缀列表经常变化、写入比较频繁 —— 考虑用 计算列 + 普通索引,或干脆只保留一个 suffix 全索引。

2. 索引变动时,要不要“改数据库”?

  • 只改后缀列表(例如给 video 加 m2v):

    • 对部分索引:必须 重建或新增索引 才能覆盖新后缀。常见做法
      sql
      -- 并行、不锁表地重建 CREATE INDEX CONCURRENTLY idx_video_new ON files(suffix) WHERE suffix IN ('mp4', 'avi', ..., 'm2v'); -- 回收旧索引 DROP INDEX CONCURRENTLY idx_video;
    • 对完整索引或 file_type 方案:无需动索引,只要更新映射/计算列逻辑。
  • 修改表结构(列名、数据类型变更)

    • 任何索引都依赖列定义,列本身变更时需要 DROP/RECREATEALTER INDEX ... ALTER COLUMN(能否 ALTER 取决于数据库,PostgreSQL 只能重建)。
  • 改存储引擎/集群拓扑

    • 这属于运维层面,需要评估空间 & 重建时间,通常在维护窗口使用 REINDEX 或迁移脚本。

3. 推荐的运维流程

  1. 版本化 SQL:将所有索引 DDL 放在版本控制里(如 Flyway / Liquibase),变更走迁移脚本。
  2. 并行重建:生产环境使用 CREATE INDEX CONCURRENTLY & DROP INDEX CONCURRENTLY,避免长时间锁表。
  3. 监控 & 分析:定期用 pg_stat_user_indexesEXPLAIN 检查命中率;若部分索引长期 0 usage,可以下线。
  4. 自动化脚本:如果后缀列表来自配置文件(如你贴的 JSON),可写脚本自动生成 DDL,减少手工遗漏。

一句话建议

若后缀分类很少变且查询高并发,用你现在的“按分类部分索引”即可;
若后缀经常增删,请考虑“计算列 + 单列索引”或直接一个完整索引,并用迁移脚本管理索引重建。

分享这个问答