80 lines
5.0 KiB
JSON
80 lines
5.0 KiB
JSON
|
{
|
||
|
|
"topic": "database-advanced",
|
||
|
|
"type": "true_false",
|
||
|
|
"schema_version": "1.0.0",
|
||
|
|
"generated": "2026-09-09T00:00:00+08:00",
|
||
|
|
"questions": [
|
||
|
|
{
|
||
|
|
"id": "tf-001",
|
||
|
|
"type": "true_false",
|
||
|
|
"difficulty": 3,
|
||
|
|
"tags": [
|
||
|
|
"mysql",
|
||
|
|
"bplus-tree",
|
||
|
|
"composite-index"
|
||
|
|
],
|
||
|
|
"question": "在MySQL中，对于联合索引(a, b, c)，当查询条件为 WHERE b = 1 AND c = 2 时，优化器可以自动调整条件顺序以匹配索引最左前缀，从而使用该索引。",
|
||
|
|
"answer": false,
|
||
|
|
"explanation": "联合索引(a, b, c)要求查询条件必须从最左列a开始才能命中索引。优化器虽然可以重排WHERE子句中条件的执行顺序（将 b=1 AND c=2 调整为 c=2 AND b=1），但无论怎么调整，条件中始终缺少最左列a，因此该联合索引完全无法被使用。最左前缀原则是B+树联合索引的物理存储结构决定的——索引按照(a, b, c)的顺序排序，没有a的值就无法在B+树上进行有效的范围定位。",
|
||
|
|
"source": null,
|
||
|
|
"related": []
|
||
|
|
},
|
||
|
|
{
|
||
|
|
"id": "tf-002",
|
||
|
|
"type": "true_false",
|
||
|
|
"difficulty": 2,
|
||
|
|
"tags": [
|
||
|
|
"mysql",
|
||
|
|
"explain"
|
||
|
|
],
|
||
|
|
"question": "在MySQL EXPLAIN输出中，type列的值为'index'表示全表扫描，而'ALL'表示使用了索引扫描。",
|
||
|
|
"answer": false,
|
||
|
|
"explanation": "这道题将两者搞反了。type='ALL'表示全表扫描（Full Table Scan），是最差的访问方式，需要逐行扫描聚簇索引中的所有记录。type='index'表示全索引扫描（Full Index Scan），虽然也需要扫描整个索引树，但至少使用了二级索引，在覆盖索引场景下甚至不需要回表，因此性能通常优于ALL。访问效率从好到差的典型顺序为：system > const > eq_ref > ref > range > index > ALL。",
|
||
|
|
"source": null,
|
||
|
|
"related": []
|
||
|
|
},
|
||
|
|
{
|
||
|
|
"id": "tf-003",
|
||
|
|
"type": "true_false",
|
||
|
|
"difficulty": 3,
|
||
|
|
"tags": [
|
||
|
|
"mysql",
|
||
|
|
"slow-query",
|
||
|
|
"index"
|
||
|
|
],
|
||
|
|
"question": "开启MySQL慢查询日志后，所有执行时间超过long_query_time阈值的SQL语句都会被完整记录到慢查询日志中。",
|
||
|
|
"answer": false,
|
||
|
|
"explanation": "超过long_query_time阈值的SQL并不一定会被记录，还受到min_examined_row_limit参数的影响——只有实际扫描行数超过该值的查询才会被记录。默认情况下min_examined_row_limit=0，此时所有超过阈值的查询都会被记录；但如果设置了非零值，那些虽然执行时间超标但扫描行数很少的SQL会被过滤掉。此外，慢查询日志的开启需要先设置slow_query_log=ON，且记录的是执行时间（而非锁等待时间），锁等待时间可通过log_slow_admin_statements等参数单独控制。",
|
||
|
|
"source": null,
|
||
|
|
"related": []
|
||
|
|
},
|
||
|
|
{
|
||
|
|
"id": "tf-004",
|
||
|
|
"type": "true_false",
|
||
|
|
"difficulty": 4,
|
||
|
|
"tags": [
|
||
|
|
"mysql",
|
||
|
|
"lock"
|
||
|
|
],
|
||
|
|
"question": "InnoDB的间隙锁（Gap Lock）和临键锁（Next-Key Lock）在读已提交（READ COMMITTED）隔离级别下仍然生效，用于防止幻读。",
|
||
|
|
"answer": false,
|
||
|
|
"explanation": "间隙锁和临键锁只在可重复读（REPEATABLE READ）及以上隔离级别下生效。在读已提交（READ COMMITTED）级别下，InnoDB仅使用记录锁（Record Lock）锁定索引记录本身，不会对索引记录之间的间隙加锁。这意味着RC级别下无法防止幻读——另一个事务可以在间隙中插入新记录。这是MySQL默认选择RR作为隔离级别的重要原因之一：通过间隙锁+临键锁在RR级别下实现幻读防护。注意意向锁（Intention Lock）和元数据锁（MDL）在所有隔离级别下都存在，它们与间隙锁是不同层面的锁机制。",
|
||
|
|
"source": null,
|
||
|
|
"related": []
|
||
|
|
},
|
||
|
|
{
|
||
|
|
"id": "tf-005",
|
||
|
|
"type": "true_false",
|
||
|
|
"difficulty": 3,
|
||
|
|
"tags": [
|
||
|
|
"redis",
|
||
|
|
"cluster"
|
||
|
|
],
|
||
|
|
"question": "在Redis Cluster中，当某个master节点负责的slot持续无法被访问时，该master的slave会自动发起投票选举并完成故障转移，客户端通过MOVED或ASK重定向自动感知拓扑变化。",
|
||
|
|
"answer": true,
|
||
|
|
"explanation": "Redis Cluster的故障转移机制如下：1) 每个master节点定期向其他节点发送PING，当某个master被标记为PFAIL（疑似下线）后，集群通过Gossip协议传播该状态；2) 当超过半数的master节点都将该节点标记为FAIL时，其slave会发起选举，通过类似Raft的投票机制竞争晋升为新master；3) 获得多数投票的slave被提升为master，接管原master负责的slot，并向集群广播配置更新。客户端收到MOVED响应后会更新本地路由表，后续请求直接发往新master，整个过程对应用层基本透明。值得注意的是，Redis Cluster默认需要至少3个master节点且每个master至少1个slave才能保证高可用。",
|
||
|
|
"source": null,
|
||
|
|
"related": []
|
||
|
|
}
|
||
|
|
]
|
||
|
|
}
|