m0_61802230的博客

导语大家知道binlog可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了binlog就可以跟主库保持一致了呢？我下面的内容就是针对这个问题。MySQL主备的基本原理在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库。**注意：节点B（也就是备库）设置成只读（readonly）模式。**主要有以下几个原

问题我们知道，只要redo log和bin log保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复。那他们是如何持久化到磁盘的呢？今天就探讨这个问题？binlog的写入机制事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。但是我们要明确，一个事务的binlog是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这就涉及到了binlog cache的保存问题。系统给binlog cache分配了一片内存，每个

问题首先要明确你的数据库突然压力变大是因为什么，之后才能采取出相应的措施来解决。短连接过多那什么是短连接呢？正常的短连接模式就是连接到数据库后，执行很少的SQL语句就断开，下次需要的时候再重连。如果使用的是短连接，在业务高峰期的时候，就可能出现连接数突然暴涨的情况。我们知道在MySQL建立连接的过程，成本是很高的。除了正常的网络连接三次握手外，还需要做登录权限判断和获得这个连接的数据读写权限。在数据库压力比较小的时候，这些额外的成本并不明显。短连接模型存在一个风险，就是一旦数据库处理得慢一

先说明：Mysql 在Repeatable Read底下不会发生幻读的情况，因为Mysql有间隙锁的可以防止幻读。那什么是间隙锁？间隙锁跟MVCC一起工作。实现事务处理：Repeatable Read隔离级别： 采用Next-key Lock 来解决幻读问题.因此 Mysql 在Repeatable下面 幻读，可重复读，脏读 三者都不会发生read committed隔离级别：采用Record锁,不会出现脏读，但是会产生"幻读"问题. 也会出现可重复读。什么是MVCC 呢？MVCC只是工

问题描述在MySQL中，有很多看上去逻辑相同，但性能却差异巨大的SQL语句。对这些语句使用不当的话，就会不经意间导致整个数据库的压力变大。案例分析条件字段函数操作对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。不过优化器在个问题上确实有“偷懒”行为，即使是对于不改变有序性的函数，也不会考虑使用索引。比如，对于select * from tradelog where id + 1 = 10000这个SQL语句，这个加1操作并不会改变有序性，但是MySQL优化器还是不

count()的语义count()是一个聚合函数，对于返回的结果集，一行行地判断，如果count函数的参数不是NULL，累计值就加1，否则不加。最后返回累计值。需要注意的是，下面的讨论是基于InnoDB引擎的。count(*)、count(主键id)和count(1)首先说明一点，count(*)、count(主键id)和count(1) 都表示返回满足条件的结果集的总行数；而count(字段），则表示返回满足条件的数据行里面，参数“字段”不为NULL的总个数。至于分析他们之间性能差别的时候，可以

基础架构MySQL的基本架构示意图大体来说，MySQL可以分为Server层和存储引擎层两部分。Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开