通过规范化数据库设计、合理使用复合主键和索引、避免不必要的重复字段，能有效消除数据冗余并提升查询效率。

来源1

在数据库设计中，复合属性通常指由多个简单属性组合而成的属性，比如姓名（姓+名）、地址（省+市+区）。如果直接将复合属性作为一个字段存储，会导致数据冗余和更新异常。例如，一个人的地址如果存为“北京市朝阳区某路”，修改区名时需要更新所有相关记录。正确的做法是将省、市、区分解为独立字段，并通过外键关联地址表。

来源2

为了避免数据冗余，数据库规范化是关键。第一范式要求消除重复组，第二范式消除部分依赖，第三范式消除传递依赖。对于复合主键，如订单表（订单ID + 商品ID），确保每个属性都参与决定非主属性。实际案例：电商订单表中，不要在订单详情重复存商品名称，而应关联商品表。

来源3

查询效率低下常见于缺少索引或索引设计不当。对于复合属性查询，如经常按姓名和地址筛选用户，应创建复合索引（姓名, 地址）。MySQL 示例：CREATE INDEX idx_name_addr ON users(name, address); 这能覆盖查询，避免全表扫描。测试显示，添加后查询时间从2s降到50ms。

来源4

数据冗余的另一个问题是多对多关系处理不当。比如学生选课，如果在学生表存所有课程，会重复课程信息。解决方案：用中间表，学生表-选课中间表（学生ID+课程ID）-课程表。这样更新课程只需改一处，避免连锁更新。

来源5

在设计复合属性时，考虑业务场景。员工信息中，复合属性“部门职位”可拆为部门ID和职位ID，关联部门表和职位表。避免在主表存描述性文本，用JOIN查询。经验：优先使用数值ID而非字符串，减少存储空间并加速比较。

来源6

低效查询往往因笛卡尔积或不当JOIN引起。对于复合属性，预聚合视图可帮助，但别过度用视图替换表。PostgreSQL 示例：CREATE VIEW user_summary AS SELECT u.id, u.name, d.dept_name FROM users u JOIN depts d ON u.dept_id = d.id; 定期分析EXPLAIN计划，优化慢查询。

来源7

实际项目中，我们遇到库存表数据冗余：每个订单行重复存商品规格。重构后，用规格表+JSON字段存储复合属性变体，既灵活又无冗余。查询用GIN索引支持JSON路径，提升效率30%。

FAQ

Q: 什么是复合属性？
A: 复合属性是由多个基本属性组合成的，比如完整地址由省、市、区组成。

Q: 如何快速避免数据冗余？
A: 通过数据库范式规范化，将重复数据提取到独立表，用外键关联。

Q: 复合索引什么时候用？
A: 当查询总是按多个字段顺序过滤时，用复合索引覆盖这些字段。

Q: 规范化会影响查询性能吗？
B: 会增加JOIN次数，但通过索引优化，通常性能更好，且数据一致性高。