为船用设备状态监控系统设计数据库表结构，需存储设备ID、状态（运行/故障）、故障代码、时间戳等信息，请说明表结构设计及索引策略，并解释为何选择该设计。

1) 【一句话结论】为船用设备状态监控系统设计设备状态监控表，通过主键（设备ID+时间戳）和辅助索引（状态、故障代码、时间范围）优化查询与写入，满足实时状态记录与故障追溯需求。

2) 【原理/概念讲解】数据库表设计需平衡数据完整性与查询效率。核心字段：设备ID（唯一标识设备，如UUID或自增ID）、状态（枚举类型，如'运行'/'故障'，减少存储冗余）、故障代码（故障类型编码，如INT或字符串，需规范编码）、时间戳（记录状态变更时间，如TIMESTAMP，用于排序与时间范围查询）。索引策略：主键（设备ID+时间戳）保证唯一性，并支持高效查询；辅助索引（状态、故障代码、时间戳）加速特定条件查询（如查询某设备故障记录、某故障类型的设备）。类比：设备状态记录类似日志，时间戳是时间线，索引如同书籍目录，快速定位特定时间或状态的记录。

3) 【对比与适用场景】

索引类型	定义	特性	使用场景	注意点
主键索引（设备ID+时间戳）	唯一标识每条记录的组合键	B树结构，唯一性，支持高效查询与写入（主键约束强制唯一）	设备状态变更的每条记录，需唯一标识	主键选择需考虑性能与存储，如UUID可能比自增ID存储开销大
状态索引（状态列）	索引状态字段	B树索引，支持范围查询（如查询所有故障状态）	快速查询某状态下的设备记录（如统计故障设备数量）	状态字段为枚举，索引效率高，但写入时需更新状态，可能增加索引维护成本
故障代码索引	索引故障代码列	B树索引，支持故障类型查询（如查询某故障代码的设备）	快速检索特定故障类型的记录（如分析某故障的设备分布）	故障代码需规范编码，避免冗余，如使用标准故障代码库
时间范围索引（时间戳）	索引时间戳列	B树索引，支持时间范围查询（如查询最近24小时的状态记录）	实时监控与历史数据查询（如查看设备最近状态变化）	时间戳精度（如毫秒级）需根据需求选择，高精度可能增加存储与索引开销

4) 【示例】

CREATE TABLE device_status (
    device_id VARCHAR(36) NOT NULL,  -- 设备唯一标识，如UUID
    status VARCHAR(10) NOT NULL,     -- 状态：'运行'/'故障'
    fault_code INT NOT NULL,          -- 故障代码（如1=电机故障，2=传感器异常）
    timestamp TIMESTAMP NOT NULL,     -- 状态变更时间，默认当前时间
    PRIMARY KEY (device_id, timestamp),  -- 主键：设备+时间，唯一标识每条记录
    INDEX idx_status (status),         -- 索引状态，加速状态查询
    INDEX idx_fault_code (fault_code), -- 索引故障代码，加速故障类型查询
    INDEX idx_timestamp (timestamp)    -- 索引时间戳，加速时间范围查询
);

5) 【面试口播版答案】
“面试官您好，针对船用设备状态监控系统，我设计的表结构是device_status，包含设备ID、状态、故障代码、时间戳等字段。具体来说：

• 设备ID用UUID（或自增ID）作为主键，确保每条记录唯一；
• 状态字段用枚举（如'运行'/'故障'），减少存储冗余；
• 故障代码用整数编码（如标准故障库），便于查询；
• 时间戳记录状态变更时间，支持时间范围查询。
  索引策略方面，主键（设备ID+时间戳）保证唯一性，并支持高效查询；辅助索引（状态、故障代码、时间戳）加速特定条件查询（如查询故障设备、某故障类型的记录）。这样设计能高效存储设备状态变更，快速查询故障记录，满足实时监控与故障追溯需求。”

6) 【追问清单】

• 问：为什么选择设备ID+时间戳作为主键？
  答：因为每条设备状态记录由设备唯一标识和时间唯一标识，组合主键能唯一区分记录，且支持按设备或时间排序查询。
• 问：故障代码用整数还是字符串？为什么？
  答：用整数（如标准故障编码），因为整数存储更高效，且便于索引和查询，同时可通过编码规范避免冗余。
• 问：时间戳精度选毫秒还是秒？
  答：根据需求，若需要精确到分钟内查询，用秒级；若需要精确到秒内，用毫秒级，但需考虑存储开销。
• 问：数据量很大时，如何优化？
  答：可按设备ID分表（如按设备ID哈希分表），或按时间范围分表（如按天分表），减少单表数据量，提升查询性能。
• 问：状态字段用字符串还是枚举？
  答：用枚举（如'运行'/'故障'），因为枚举类型能减少存储冗余，且查询时更高效（如索引状态字段可快速统计故障设备数量）。

7) 【常见坑/雷区】

• 坑1：主键设计不当（如用字符串拼接，导致索引效率低或存储开销大）。
  雷区：应选择高效的主键，如UUID或自增ID，确保主键索引性能。
• 坑2：状态字段用字符串而非枚举，导致存储冗余或查询效率低。
  雷区：状态字段为固定枚举值，应定义为ENUM类型，减少存储空间，并支持索引。
• 坑3：未考虑时间范围查询的索引，导致查询慢。
  雷区：时间戳字段需建立索引，否则时间范围查询（如SELECT * FROM device_status WHERE timestamp > '2023-01-01 00:00:00'）会全表扫描。
• 坑4：故障代码未规范化，导致数据冗余或查询混乱。
  雷区：故障代码应遵循标准编码（如ISO或行业规范），避免自定义编码导致数据不一致。
• 坑5：索引过多导致写入性能下降。
  雷区：主键索引是必须的，辅助索引需根据查询需求选择，避免不必要的索引（如状态字段若更新频繁，索引维护成本高，可能影响写入性能）。