移动端应用中，如何设计本地数据库（如SQLite）的表结构，以高效存储用户消息、联系人列表，并优化查询性能（如索引、事务处理）。请说明如何保证数据安全（如加密存储），以及如何处理数据迁移（如版本升级）。

Tencent软件开发-移动客户端开发方向难度：中等

答案

1) 【一句话结论】
移动端本地数据库设计需以“结构化存储+索引精准优化+事务边界控制+安全加密+版本兼容”为核心，通过合理表结构（如消息表关联联系人、多字段索引）、事务管理（批量操作分批处理）、字段级加密（KeyStore管理密钥）、SQLite schema版本控制（onUpgrade处理迁移），高效存储消息与联系人，保障查询性能与数据安全。

2) 【原理/概念讲解】
老师口吻：咱们先讲表结构设计，消息和联系人得清晰区分。比如消息表要包含“消息ID（主键）”“发送方ID（外键关联联系人）”“接收方ID（外键关联联系人）”“内容”“时间戳”“状态（如未读/已读）”这些字段，这样能快速定位消息。联系人表则包含“ID（主键）”“姓名”“手机号（唯一索引，方便快速查人）”“备注”等。

索引是提升查询的关键，比如消息表用“发送方ID+接收方ID”做联合索引，因为多条件筛选（如找A发给B的未读消息）常用；按“时间戳”建索引，方便按时间排序。事务处理也很重要，比如批量插入消息时用事务保证原子性，避免数据不一致。数据安全方面，对手机号、消息内容这类敏感字段，用AES加密存储，密钥通过系统KeyStore管理，防止数据泄露。数据迁移时，通过SQLite的schema版本控制（onUpgrade方法），处理结构变更（如新增字段、索引），迁移旧数据到新结构，确保兼容性。

（类比：表结构像“仓库分类”，索引像“仓库标签”，事务像“批量操作打包”，加密像“数据锁”，迁移像“仓库升级”）

3) 【对比与适用场景】

对比维度	方案	定义/特性	使用场景	注意点
索引类型	主键索引	唯一自增ID，自动维护	表主键（如消息ID、联系人ID）	不能为空，需唯一
索引类型	单列索引	单个字段索引	查询频繁的单字段（如时间戳、状态）	避免冗余，维护成本高
索引类型	联合索引	多字段组合索引	多条件筛选（如按发送方+时间排序）	遵循“最左前缀”原则，避免部分匹配
数据安全	明文存储	未加密存储	非敏感数据（如联系人备注）	风险高，仅用于非敏感场景
数据安全	字段级加密（AES）	对字段加密，密钥管理	敏感数据（如手机号、消息内容）	需妥善管理密钥，避免泄露
数据迁移	自动版本控制（SQLite onUpgrade）	结构变更（新增字段、索引）	大规模数据迁移	确保兼容性，避免数据丢失
数据迁移	手动脚本迁移	小规模数据迁移	临时场景	容易出错，不推荐大规模使用

4) 【示例】

表结构设计（伪代码）：

-- 联系人表
CREATE TABLE contacts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    phone TEXT UNIQUE NOT NULL,
    notes TEXT
);

-- 消息表
CREATE TABLE messages (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    sender_id INTEGER NOT NULL,
    receiver_id INTEGER NOT NULL,
    content TEXT NOT NULL,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    status INTEGER DEFAULT 0, -- 0:未读, 1:已读
    FOREIGN KEY (sender_id) REFERENCES contacts(id),
    FOREIGN KEY (receiver_id) REFERENCES contacts(id),
    INDEX idx_sender_receiver (sender_id, receiver_id),
    INDEX idx_timestamp (timestamp)
);

事务处理示例（批量插入消息）：

BEGIN TRANSACTION;
INSERT INTO messages (sender_id, receiver_id, content) VALUES (1, 2, 'Hello');
INSERT INTO messages (sender_id, receiver_id, content) VALUES (2, 1, 'Hi');
COMMIT;

加密存储手机号（假设使用AES和KeyStore）：

// 加密手机号
String encryptedPhone = encrypt(phone, key);
INSERT INTO contacts (phone) VALUES (encryptedPhone);

5) 【面试口播版答案】
面试官您好，针对移动端本地数据库设计，核心是围绕“结构化存储+索引精准优化+事务边界控制+安全加密+版本兼容”来设计。首先，表结构上，消息表通过“发送方ID+接收方ID”联合索引和“时间戳”索引，提升多条件查询（如找A发给B的未读消息）与排序性能；联系人表用手机号唯一索引，保证快速查人。事务处理上，批量消息插入时用事务保证原子性，避免数据不一致。数据安全方面，对手机号、消息内容这类敏感字段采用AES加密，密钥通过系统KeyStore管理，防止数据泄露。数据迁移时，通过SQLite的schema版本控制（onUpgrade方法），处理结构变更（如新增字段、索引），迁移旧数据到新结构，确保兼容性。这样既能高效存储消息和联系人，又保障了查询性能和数据安全。

6) 【追问清单】

问题1：如何选择索引字段？
回答要点：索引选择基于查询模式，高频查询字段建索引，避免冗余，比如消息表用“发送方+接收方”联合索引（多条件筛选常用），按“时间戳”建索引（按时间排序常用）。
问题2：数据加密的具体实现和性能影响？
回答要点：用AES加密，密钥管理用KeyStore，性能上批量操作时加密/解密有开销，可通过预加密或硬件加速优化。
问题3：数据迁移时如何处理数据丢失？
回答要点：迁移时备份旧数据，先创建新表结构，迁移数据，最后删除旧表，确保数据完整性。
问题4：联系人表手机号唯一性如何保证？
回答要点：手机号用UNIQUE约束，插入时检查唯一性，避免重复。
问题5：事务处理中如何避免死锁？
回答要点：设置事务超时时间，合理锁粒度（如按表分区锁），避免长时间锁定资源。

7) 【常见坑/雷区】

索引冗余：同时建主键和单列索引，增加存储和更新开销。
事务处理不当：未正确提交导致数据丢失，或事务过大影响性能（如批量插入100万条消息用单事务，导致锁时间过长）。
数据加密不全面：仅加密部分字段，敏感数据（如手机号、消息内容）未加密。
数据迁移时未考虑数据一致性：导致数据丢失或结构混乱（如迁移后数据校验失败，未回滚）。
索引选择错误：按时间戳建索引但查询时未用到，造成索引浪费（如查询时只按发送方ID，未用联合索引）。