【面试题】1. InnoDB 和 MyISAM 到底哪里不一样？什么场景必须用 InnoDB？

【标准答案】核心五条：一、InnoDB 支持事务和崩溃恢复，MyISAM 不支持，数据丢了就是丢了；二、InnoDB 用行级锁 + MVCC 支持高并发写，MyISAM 只有表锁，写时会阻塞所有读；三、InnoDB 数据就是聚簇索引，主键和数据绑在一起，MyISAM 数据和索引分离；四、InnoDB 从 5.6 起支持全文索引，MyISAM 的老优势基本磨平；五、InnoDB 支持外键约束。结论就一句话：只要你的业务有写操作、需要数据不丢，无脑选 InnoDB。MyISAM 现在只剩一个场景——极致的只读日志表且内存极小，用压缩表省空间。

【面试题】2. MongoDB 的嵌入（Embed）和引用（Reference）怎么选？用错了会有什么坑？

【标准答案】嵌入是把子文档直接塞到父文档里，引用是存个关联 ID。核心判断看三个维度：数据是否一起读写、子集大小是否可控、子集是否独立变。嵌入适合"永远一起取"的数据，比如用户标签、收货地址列表，一次查询全拿到了，不用 join。引用适合独立实体，比如订单和商品——商品信息频繁变，嵌进去就全废了。用错的代价：该嵌入却用引用，查一次要手动拼两次，线上性能崩；该引用却嵌入，一个文档从几 KB 胀到几十 MB，更新一个字段整个文档全重写，还容易触发文档迁移导致写放大的不归路。

【面试题】3. Hive 和 HBase 都是 Hadoop 生态的存储，什么时候用哪个？

【标准答案】一句话：Hive 是 SQL on Hadoop 的数仓引擎，适合批量离线分析；HBase 是实时的 NoSQL 宽表存储，适合海量随机读写。Hive 底层是 MapReduce/Tez，一次查询分钟级，但 TB 级聚合很能打；HBase 基于 LSM-Tree，毫秒级读写，但聚合要自己写代码。架构上 Hive 数据存 HDFS，Schema on Read；HBase 数据存 HDFS 上的 HFile，Schema 写入时就定好了。选型口诀：做 BI 报表、ETL 加工、天级别分析用 Hive；做用户画像标签毫秒点查、时序数据、增量消息存储用 HBase。别拿 Hive 做实时服务，也别拿 HBase 做 join 大宽表。

【面试题】4. MySQL 读写分离下主从延迟怎么处理？有哪些落地套路？

【标准答案】核心思路三层递进。第一层，能忍就忍：很多业务（后台管理、报表展示）几百毫秒延迟无所谓，直接用从库读就行。第二层，不能忍就强制走主库：关键链路（下单后立刻查订单、支付回调校验）直接在代码里标记走主库，用注解或路由规则，比如插入后的关键查询强制读主。第三层，智能路由：监听从库延迟，超过阈值自动切主，恢复正常再切回。工具上 MHA/Orchestrator 做高可用切换，ProxySQL/MaxScale 做透明路由，代码里用 ShardingSphere-JDBC 的 HintManager 手动指定。原则就一条：延迟敏感的核心链路宁可多压主库也别读错数据。

【面试题】5. SQL 里的隐式类型转换为什么会让索引失效？怎么排查和避免？

【标准答案】MySQL 里当查询条件的字段类型和传入值的类型不匹配时，它会偷偷做类型转换，比如字符串字段用数字去查，底层相当于把字段 CAST 成数字再比较——但 CAST 后的字段不再是原来的索引值，优化器发现用不上索引就直接全表扫了。排查很简单：EXPLAIN 看到 key 列是 NULL、type 是 ALL，把 WHERE 条件里的值加上引号再 EXPLAIN 一次，type 变成 range/ref 就找到问题了。避免方法：代码里 SQL 参数类型和表字段类型严格对齐，int 字段不要传字符串，varchar 字段不要传数字。建表时别用 varchar 存数字——这坑我见过太多次了。

【面试题】6. Hadoop 的 NameNode 是单点故障，生产上怎么解决？HA 原理是什么？

【标准答案】Hadoop 2.x 引入了 NameNode HA，核心是两个 NameNode 一主一备，共享 edits log 通过 Quorum Journal Manager（奇数个 JournalNode）来同步元数据。主 NameNode 把所有元数据操作写入 JournalNodes，备 NameNode 持续拉取并合并到自己的 fsimage，保证状态实时同步。ZK 负责故障检测和主备切换——主挂掉 ZK 触发 fencing，备提升为主。关键细节：JournalNode 必须奇数个（3 最常见），过半写成功才算完成；fencing 是防脑裂的，旧主以为自己还活着就强制杀。社区后来推的 Federation 更进一步，多组 NameNode 各管一部分目录，彻底打破单点性能瓶颈。

【面试题】7. 上亿数据量的表加索引，你会怎么操作才不影响线上？

【标准答案】在线加索引是个高危操作，MySQL 5.6 开始 Online DDL 不锁表，但大表还是吃 IO 和 CPU。我的流程：第一，首选 PT-OSC（Percona Toolkit Online Schema Change），它创建一个影子表，把数据分批同步，最后原子切换表名，全程不锁表只会有短暂元数据锁。第二次选 gh-ost，GitHub 开源的，更轻量，基于 binlog 捕获增量变更。第三，如果只能用 ALTER TABLE，必须设 ALGORITHM=INPLACE LOCK=NONE 避免锁表。第四，操作时间选凌晨低谷，监控磁盘 IO 和从库延迟。第五，加完立刻 ANALYZE TABLE 更新统计信息。一句话总结：脚本化 > 手动敲命令，pt-osc > online DDL > 原生 ALTER。

【面试题】8. 数据湖三剑客 Iceberg、Hudi、Delta Lake 怎么选？各自的适用场景是什么？

【标准答案】三者都是给数据湖加 ACID 和版本管理，但侧重点不同。Delta Lake 和 Spark 生态绑定最深，Delta Table 就是带事务日志的 Parquet，适合 Databricks 全家桶用户，对Spark SQL 优化极好。Hudi 做增量 upsert 最强，支持 Copy On Write 和 Merge On Read 两种模式，对 CDC 入湖有原生优化，适合实时数据摄入和近实时分析。Iceberg 最开放、表格式最干净，隐藏文件级的物理细节，查询引擎不用关心底层文件布局，跨引擎兼容性最好（Spark、Flink、Trino、Presto 都原生支持）。选型：和 Databricks 深度绑定选 Delta；CDC 入湖需求重选 Hudi；追求引擎无关和开放生态选 Iceberg。国内互联网 Iceberg 用得越来越多，趋势明显。

【面试题】9. 数据库选型时，你会用哪几个维度来评估？试举一个实际场景。

【标准答案】我通常拉五个维度：数据模型（结构化/半结构化/时序）、读写模式（读多写少/高并发写/批量分析）、一致性要求（强一致/最终一致）、数据量级和增长预期、团队运维能力。举例：做一个千万级的物联网设备上报系统，核心特征是写多读少、时序数据、每天十亿条。我不会选 MySQL——单表扛不住，分库分表后时间范围查询很难做。我的选型是：写入走 Kafka 削峰，用 ClickHouse 或 TimescaleDB 做分析存储，Redis 缓存热点设备最新状态。如果团队没有 ClickHouse 运维经验，我就退一步用 Doris，运维门槛更低，OLAP 能力也够。选型不追求最牛逼，追求最合适。

【面试题】10. 一个核心服务 QPS 突然从 5000 掉到 500，你怎么快速定位和恢复？

【标准答案】八分钟内要出结果。第一分钟：看监控大盘——CPU、IO、连接数、慢查询瞬间飙升是谁？确认是不是 DB 问题。第二分钟：show full processlist 看大量连接卡在什么状态，Sending data 还是 Waiting for lock？第三分钟：查锁争用，查 information_schema.innodb_trx、innodb_lock_waits，看有没有长事务堵了一堆。第四分钟：看 buffer pool 命中率是不是被某个大查询给冲了。第五分钟：不是 DB 的问题就看上游，是不是 Redis 挂了请求全压到 DB 了，或者限流没配好。恢复：锁就直接 kill 阻塞事务；大查询 kill + 加索引；缓冲池被冲就重启应用降低连接数同时限流。事后再深挖定位——慢日志分析、AWR/STATEMENTS 历史。核心原则：先恢复再排查，保命第一位。