1. 数据库面试核心考察维度解析数据库作为后端开发的基石技术在技术面试中的考察权重通常超过40%。根据近三年一线互联网企业的实际面试统计数据库相关问题的出现频率高达92.7%其中高频考点集中在以下五个维度1.1 存储引擎与架构原理面试官常通过存储引擎差异考察候选人对底层机制的理解深度。以MySQL为例需要掌握InnoDB的B树索引实现默认高度3-4层单页16KB、行锁升级为表锁的触发条件如无索引更新。我曾遇到一个典型案例某电商平台在促销期间出现大量锁等待最终定位是未对user_id字段建立索引导致全表扫描锁升级。关键记忆点InnoDB的MVCC实现通过DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID三个隐藏字段完成版本控制这与PostgreSQL的多版本实现有本质区别。1.2 SQL优化与执行计划真实业务场景的SQL优化能力是区分初级与中级开发者的重要标尺。需要熟练掌握EXPLAIN的各项输出指标type列从优到劣依次为system const eq_ref ref range index ALLExtra列重点关注Using filesort需要额外排序和Using temporary使用临时表典型优化案例某日志表查询从12秒优化到0.3秒通过将SELECT * FROM logs WHERE create_time 2023-01-01 ORDER BY user_id改为联合索引(user_id, create_time)避免了filesort操作。1.3 事务与并发控制ACID特性需要结合具体数据库实现来理解。重点掌握事务隔离级别MySQL默认为REPEATABLE-READ但通过间隙锁实现部分SERIALIZABLE特性死锁检测InnoDB使用wait-for graph算法检测到死锁后会回滚代价较小的事务乐观锁实现版本号控制UPDATE table SET valnew_val, versionversion1 WHERE id1 AND versionold_version1.4 高可用架构设计分布式数据库方案是高级工程师必考内容包括主从复制延迟解决方案GTID、半同步复制分库分表策略Range分片 vs Hash分片中间件对比ShardingSphere与MyCat的适用场景差异1.5 新型数据库技术近年面试新增考点包括时序数据库InfluxDB的TSM存储结构图数据库Neo4j的Cypher查询语法向量数据库Milvus的近似最近邻搜索算法2. 高频面试题深度剖析2.1 索引失效的七大场景通过实际案例说明索引失效原理隐式类型转换WHERE phone13800138000phone是varchar类型函数操作WHERE DATE(create_time)2023-01-01前导模糊查询WHERE name LIKE %张OR条件未全覆盖WHERE a1 OR b2仅a有索引不符合最左前缀索引(a,b,c)但查询WHERE b1 AND c2使用!或操作符数据倾斜严重索引列90%都是相同值2.2 亿级数据分页优化传统LIMIT 1000000,10方案存在严重性能问题优化方案对比方案原理适用场景缺点延迟关联先查ID再回表排序字段有索引仍需扫描大量记录书签记录记录上次查询位置顺序翻页无法跳页索引覆盖子查询利用覆盖索引避免回表查询字段在索引中复杂SQL业务折衷禁止跳页/限制最大页码用户可接受功能受限最佳实践SELECT * FROM table WHERE id 1000000 ORDER BY id LIMIT 10配合ID自增条件。2.3 分布式ID生成方案对比各种方案实现细节UUID优点本地生成无网络开销缺点无序导致索引效率低InnoDB的聚集索引特性数据库序列优化方案使用REPLACE INTOseq(stub) VALUES (a); SELECT LAST_INSERT_ID();瓶颈单点问题TPS约2000雪花算法结构1bit符号位 41bit时间戳 10bit机器ID 12bit序列号问题时钟回拨解决方案等待/报警号段模式实现每次获取一个号段如1-1000优化双Buffer交替使用3. 事务隔离级别实战案例3.1 幻读现象重现建表语句CREATE TABLE account ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(20) NOT NULL, balance int(11) NOT NULL, PRIMARY KEY (id), KEY idx_name (name) ) ENGINEInnoDB;事务时序事务ASELECT * FROM account WHERE name LIKE 张%;返回2条事务BINSERT INTO account(name,balance) VALUES(张三,100); COMMIT;事务ASELECT * FROM account WHERE name LIKE 张%;仍返回2条事务AUPDATE account SET balance200 WHERE name LIKE 张%;影响3行事务ASELECT * FROM account WHERE name LIKE 张%;返回3条现象说明REPEATABLE-READ下出现幻读的根本原因是范围查询无法通过快照读避免新增记录。3.2 间隙锁触发条件测试表CREATE TABLE gap_lock ( id int(11) NOT NULL, val int(11) DEFAULT NULL, PRIMARY KEY (id), KEY idx_val (val) ) ENGINEInnoDB; INSERT INTO gap_lock VALUES (1,10),(3,10),(5,20),(7,20),(9,30);锁测试场景场景1SELECT * FROM gap_lock WHERE val20 FOR UPDATE;锁定范围(10,20], (20,30) 的间隙场景2SELECT * FROM gap_lock WHERE id BETWEEN 3 AND 7 FOR UPDATE;锁定记录id3,5,7 锁定间隙(1,3), (3,5), (5,7), (7,9)4. 性能优化实战技巧4.1 慢查询日志分析流程开启配置slow_query_log ON long_query_time 1 log_queries_not_using_indexes ON分析工具使用mysqldumpslow -s t /var/log/mysql-slow.log | head -10 pt-query-digest /var/log/mysql-slow.log slow_report.txt典型案例处理临时表过大调整tmp_table_size默认16MB文件排序检查sort_buffer_size默认256KB索引缺失使用pt-index-usage分析4.2 连接池参数调优以HikariCP为例的关键参数参数推荐值计算依据maximumPoolSize(核心数*2)有效磁盘数避免上下文切换开销minimumIdle同maximumPoolSize生产环境建议保持一致connectionTimeout3000ms略大于平均查询耗时idleTimeout600000ms10分钟回收防止连接泄漏maxLifetime1800000ms30分钟避免数据库连接超时监控指标Active Connections应稳定在maximumPoolSize的70%以下Connection Creation Rate突增可能预示连接泄漏5. 新型数据库技术考点5.1 时序数据库核心优化InfluxDB的存储引擎优化点TSM文件结构按时间范围分片通常1小时列式存储压缩Delta编码ZSTD倒排索引优化Tag值字典化存储Series文件内存映射查询加速预聚合CONTINUOUS QUERY下推WHERE time now() - 1h5.2 向量数据库检索原理以Milvus为例的近似最近邻搜索流程向量预处理归一化L2归一化量化PQ/IVF-PQ索引构建IVF_FLAT倒排文件原始向量HNSW层级化NSW图查询过程search_params {metric_type: L2, params: {nprobe: 10}} results collection.search(vectors, embedding, paramsearch_params, limit10)性能对比100万768维向量FP32精度IVF_SQ8构建时间12s查询延迟8ms召回率98%HNSW构建时间45s查询延迟3ms召回率99%