设置mysql主从复制：数据库改写非常频繁，输入FLUSH TABLES WITH READ LOCK锁定数据库，锁定会花很长时间吗？

kunkunqian 2014-08-28 04:12:45

在主服务器上输入show master status后Position的值变化的非常快，输入FLUSH TABLES WITH READ LOCK后Position的值会暂停下来吗？

...全文

229 1 打赏收藏转发到动态举报

写回复

用AI写文章

1 条回复

切换为时间正序

请发表友善的回复…

发表回复

九月茅 2014-08-28

打赏
举报

flush tables with read lock请求全局read lock。当这种情况发生时，其他进程如果有修改动作的话就会被阻塞。从理论上讲，这种情况并不是很糟糕，因为flush tables with read lock只需要read lock，其它命令（只需要read lock的命令）可以和flush tables with read lock并存。然而，事实上，大多数表需要读和写锁的。例如：第一个写语句会被这个全局的读锁阻塞，而子查询又会被第一个写语句阻塞，所以真正有效果的是使用的是排它锁，所有新请求就会被阻塞，包括读查询语句。

本文系统梳理MySQL核心机制，涵盖SQL执行流程（连接器、查询缓存、解析器、优化器、执行器）、事务实现（两阶段提交、MVCC、redo log与binlog协同）、索引底层（B+树选型、覆盖索引、change buffer）、锁机制（行锁/间隙锁/临键锁、MDL、死锁分析）、存储引擎（InnoDB脏页刷写、Buffer Pool）、高可用（主从复制、读写分离）及安全防护（SQL注入防御）。重点聚焦InnoDB事务一致性保障与性能调优实践。

本文系统梳理MySQL 8.0核心知识体系，涵盖DDL/DML/DQL/DCL四大语言、InnoDB存储引擎架构、B+Tree索引结构与失效场景、事务ACID特性及MVCC多版本并发控制机制、redo/undo日志原理、锁机制（行锁/间隙锁/临键锁）、性能分析工具（EXPLAIN/profile/慢日志）、SQL优化策略（索引设计、分页/排序/聚合优化）以及高可用方案（主从复制、分库分表与ShardingSphere应用）。内容聚焦数据库内核机制与生产级调优实践。

本文系统讲解MySQL核心机制，涵盖InnoDB存储引擎、B+Tree索引结构、覆盖索引与最左前缀法则、索引失效场景、SQL执行计划（EXPLAIN）、慢查询日志分析、事务ACID特性、MVCC多版本并发控制、隐藏字段与ReadView机制、redo/undo日志原理，以及SQL优化实践（如批量插入、order by/group by/limit优化）。

外键：用来让两张表的数据之间建立连接，从而保证数据的一致性和完整性。我们来看一个例子：左侧的emp表是员工表，里面存储员工的基本信息，包含员工的ID、姓名、年龄、职位、薪资、入职日期、上级主管ID、部门ID，在员工的信息中存储的是部门的ID dept_id，而这个部门的ID是关联的部门表dept的主键id，那emp表的dept_id就是外键,关联的是另一张表的主键。注意：目前上述两张表，只是在逻辑上存在这样一层关系，也就是逻辑外键；在数据库层面，并未建立外键关联，所以是无法保证数据的一致性和完整性的。

本文系统梳理MySQL事务ACID特性、MVCC并发控制机制、B+树索引原理及优化策略，涵盖隔离级别与幻读/脏读/不可重复读的成因与解决，锁机制（乐观锁/悲观锁）、死锁排查、SQL执行流程、redo log与binlog日志体系、主从同步与crash-safe保障机制，以及分库分表、连接池、查询优化等高可用实践。