commonBean的专栏

redo log的write pos是指写的位置，checkpoint之前表示擦除完了的。当write pos和checkpoint相遇的时候表示redo log已经写满了。这个时候数据库会停止进行更新语句的执行，转而进行redo log日志同步到磁盘中。此时数据库更新请求就会卡顿。...

https://www.jianshu.com/p/509c649f66e1

alter table tabname ENGINE=InnoDB之后原因：这个表，本身就已经没有空洞的了，比如说刚刚做过一次重建表操作。在 DDL 期间，如果刚好有外部的 DML 在执行，这期间可能会引入一些新的空洞。在重建表的时候，InnoDB 不会把整张表占满，每个页留了 1/16 给后续的更新用。也就是说，其实重建表之后不是“最”紧凑的。来源：极客时间-林晓斌整理表碎片化空间方法：alter table tabname ENGINE=InnoDB;ANALYZE TABLE t

MySQL版本：5.6.23和5.7.17现象:MySQL5.6alter table add column不阻塞insert,updatealter table modify column阻塞insert,update(不论是增加还是缩短varchar的长度)MySQL5.7alter table add column不阻塞insert,updatealter table modify column阻塞insert,update(增加varchar长度不阻塞，缩短长度会阻塞)MyS

在最近做的项目中,有一个程序上线后,SQL执行相当地慢.这个SQL在本次迭代中并没有做修改,但是却慢出天际.实在令人费解.select …from tableA a inner join tableB b on a.col=b.colwhere a.xxx in (’…’, ‘…’, ‘…’)group by a.yyyB表对A表是一对多的关系.col字段是a表索引,也是b表的主键查看执行计划除了rows一列不相同外,其他的都相同.但是当a.xxx值不相同时,查询时间却相差巨大.第一

[转载]www.fordba.com/mysql-double-quotation-marks-accident.htmlupdate tablename set source_name = “bj1062-北京市朝阳区常营北辰福第”where source_name = “-北京市朝阳区常营北辰福第”

// TODO inner join 全表扫描?不走索引? 如何解决【转载】http://www.cnitblog.com/aliyiyi08/archive/2008/09/09/48878.html±—±------------±------±------±------------------±--------±--------±------±-----±------+| id | select_type | table | type | possible_keys | key

select * from table limit 10 offset 10000;OFFSET 和 LIMIT 对于数据量少的项目来说是没有问题的。但是，当数据库里的数据量超过服务器内存能够存储的能力，并且需要对所有数据进行分页，问题就会出现。因为数据库会进行全表扫描什么是全表扫描？全表扫描 (又称顺序扫描) 就是在数据库中进行逐行扫描，顺序读取表中的每一行记录，然后检查各个列是否符合查询条件。这种扫描是已知最慢的，因为需要进行大量的磁盘 I/O，而且从磁盘到内存的传输开销也很大。...

MySQL修改表结构在5.6版本之前会锁表,从5.6版本开始OSC(Online Schema Change)线上改表,避免了锁表

问题驱动开发,原先并不知道es的这些功能,在出现问题的时候,就会去想是否能有更便捷高效的方式处理,于是经过一番查找,终于解决了这个问题.