思考并回答以下问题:
XA事务与两阶段提交
思考并回答以下问题:
- 事务具体是在存储引擎层实现的。哪些支持?
- 我们有一个大的事务,我们可以称其为全局事务,这个全局事务由若干的小的事务组成。要实现这个大的事务,就必须让它对应的若干个小的事务全部完成,或者全部回滚。我们也可以把这个大的全局事务称作分布式事务。怎么理解?
- 总揽全局的事务协调器和管理一个小事务的事务管理器都是干嘛的?
- ,要提交一个全局事务,必须分为2步:Prepare阶段和Commit阶段,这就是两阶段提交。怎么理解?
- Prepare阶段,这个阶段就是让各个事务做好提交前的准备,具体就是把语句执行过程中产生的redo日志都刷盘。如果语句执行过程中的redo日志都刷盘了,那么即使之后系统崩溃,那么在重启的时候还是可以恢复到该事务各个语句都执行完的样子。怎么理解?
- 在MySQL的外部XA实现中,MySQL服务器充当小弟,而连接服务器的客户端程序充当大哥。怎么理解?
XA START 'a'
,XA END 'a';
,XA PREPARE 'a'
,XA COMMIT 'a'
,XA ROLLBACK 'a'
都是什么意思?- MySQL的外部XA除了被用于跨行转账这种经典的分布式事务应用场景,还被广泛应用于所谓的数据库中间件。什么是数据库中间件?
- 内部XA是指MySQL内部采用XA规范来保证所有支持事务的存储引擎要么全部提交,要么全部回滚。怎么理解?
redo、undo、buffer pool、binlog,谁先谁后,有点儿乱
思考并回答以下问题:
- binlog属于server层,redo、undo属于存储引擎层。怎么理解?
- 先更新记录的聚簇索引记录,再更新记录的二级索引记录。怎么理解?
- 将记录所在的页面加载到buffer pool,先将undo日志写入Undo页面,然后再记录修改该页面对应的redo日志。在一条更新语句执行完成后(也就是将所有待更新记录都更新完了),就需要该语句对应的binlog日志了。怎么理解?
- 先在B+树中定位到该记录(这个过程也被称作加锁读)。怎么理解?
MySQL如何查看事务加锁情况
思考并回答以下问题:
- autocommit=ON是什么意思?
SELECT VERSION();SELECT @@tx_isolation;SHOW VARIABLES LIKE 'autocommit';show variables like 'binlog_format%';show variables like 'log_bin';show variables like 'slow_query_log';show variables like 'log_queries_not_using_indexes';show variables like 'long_query_time';show variables like 'slow_query_log_file';show variables like '%query%';show variables like '%log_output%';show index from t;show table status like '%t%'
。
09 | 普通索引和唯一索引,应该怎么选择?
思考并回答以下问题:
- 当需要更新一个数据页时,如果数据页在内存中就直接更新,而如果这个数据页还没有在内存中的话,在不影响数据一致性的前提下,InnoDB会将这些更新操作缓存在
change buffer
中,这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候,将数据页读入内存,然后执行change buffer
中与这个页有关的操作。怎么理解? - 将
change buffer
中的操作应用到原数据页,得到最新结果的过程称为merge。除了访问这个数据页会触发merge外,系统有后台线程会定期merge。在数据库正常关闭(shutdown)的过程中,也会执行merge操作。怎么理解? - 对于写多读少的业务来说,页面在写完以后马上被访问到的概率比较小,此时
change buffer
的使用效果最好。常见的就是账单类、日志类的系统。反过来,假设一个业务的更新模式是写入之后马上会做查询,那么即使满足了条件,将更新先记录在change buffer
,但之后由于马上要访问这个数据页,会立即触发merge过程。这样随机访问IO的次数不会减少,反而增加了change buffer
的维护代价。所以,对于这种业务模式来说,change buffer
反而起到了副作用。怎么理解?