面试选数据库需先明确业务场景：交易类用MySQL等关系型，日志类用ClickHouse/Elasticsearch，GIS需求选PostgreSQL，灵活Schema选MongoDB；表设计重主键、索引、外键取舍；分库分表看真实瓶颈；写操作须幂等、防重、批量优化，扩展预留字段并加密敏感信息。
明确业务场景再定数据库类型
面试时别一上来就说“用 MySQL”，先问清楚数据特征：是交易类系统（强一致性、事务多）还是日志/监控类（写多读少、容忍延迟）？比如订单系统必须选关系型数据库，而用户行为埋点数据更适合用 ClickHouse 或 Elasticsearch。如果业务有地理围栏需求，PostgreSQL 的 GIS 扩展比 MySQL 更成熟；若要快速迭代、字段经常变，MongoDB 的灵活 Schema 会更省力。
表结构设计紧扣核心约束和查询路径
重点讲清三件事：主键怎么选（优先自增 ID 或 UUID，避免用业务字段如手机号当主键）、索引怎么建（WHERE 和 ORDER BY 字段组合覆盖，避免冗余索引）、外键用不用（高并发写场景常去掉外键，靠应用层或定时校验保障一致性）。例如用户表和订单表，订单表的 user_id 必须加索引，如果常按“用户+时间范围”查订单，就建联合索引 (user_id, created_at)，而不是单独两个单列索引。
分库分表不是必选项，得看真实瓶颈
先说清楚什么情况下才需要：单表超 2000 万行、慢查询无法靠索引优化、主库 CPU 长期 >70%。分片策略要匹配查询习惯——按用户 ID 分片适合 C 端系统（90% 查询带 user_id），按时间分片适合日志类（查最近 N 天数据）。提醒面试官：过早分库分表会增加运维和联表难度，MySQL 8.0 + 合理索引 + 读写分离，撑住百万级日活很常见。
写操作安全与扩展性要提前留余地
INSERT/UPDATE 要考虑幂等性（加唯一索引或用 version 字段）、防重复提交（token 机制或数据库唯一约束）；批量写入用 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO，别循环单条执行。扩展方面，预留字段如 ext_json TEXT 存非结构化配置，但得说明不用于高频查询；敏感字段（手机号、身份证）必须加密存储，用 OpenSSL 扩展或数据库透明加密（TDE）方案。
立即学习“PHP免费学习笔记（深入）”；
