如何在MySQL表中存储含可变多值特性的呼叫详细记录（CDR）

针对你不想创建单独表来存储可变数量呼叫特性的需求，我整理了几个实用的思路，既能避免额外表带来的插入/清理性能问题，又能妥善存储这些可变数据：

• 使用数据库原生JSON/XML字段存储特性集合
  现在主流关系型数据库（MySQL、PostgreSQL、SQL Server等）都支持原生JSON类型（比如PostgreSQL的jsonb），你可以把XML中所有的呼叫特性转换成一个JSON数组或对象，存在主CDR表的一个单独字段里。例如：

  [{"feature_name": "呼叫保持", "duration": 150}, {"feature_name": "呼叫转移", "target_ext": "8001"}]
  

  这种方案的优势很明显：所有数据都在主CDR记录中，插入、更新、删除都只操作单条记录，完全避免了关联表的性能开销；而且JSON结构能很好地兼容任意数量的特性。如果需要按特性做查询，还可以给JSON字段添加索引（比如PostgreSQL的GIN索引），保证查询效率。

• 宽表预留特性字段+计数标记
  如果你能确定呼叫特性的类型数量是有限的（比如最多5种常见特性），可以在主CDR表中预留多组特性字段，比如feature_1_name、feature_1_value、feature_2_name、feature_2_value，再加上一个feature_total字段记录实际使用的特性数量。
  这种方案适合特性类型相对固定的场景，查询单个特性时比JSON字段更快，而且不需要额外的解析操作。缺点是扩展性稍差，如果后续出现新的特性类型，可能需要修改表结构。

• 字符串拼接存储（应急场景备选）
  如果你的数据库不支持JSON类型，可以用分隔符把特性键值对拼接成字符串存储，比如：

  呼叫保持:150|呼叫转移:8001
  

  但这个方法只适合临时应急，因为查询时需要用字符串函数解析，不仅麻烦，性能也差，而且容易出现数据格式错误，不推荐长期使用。

额外建议 #

• 如果选择JSON方案，优先用支持索引的JSON类型（如PostgreSQL jsonb、MySQL 8.0+的JSON），这样即使需要按特定特性过滤数据，也能保证性能。
• 处理XML时，可以直接在业务层把特性节点转换成JSON/结构化字段，不需要额外的中间存储步骤，进一步减少性能损耗。

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