数据库内核月报：2017年10月

【架构】  【性能优化】  【PostgreSQL】  【mysql】  【innodb】  【SQL】  【源码】  【Server】  【插件】   …

背景 有一个特殊环境需要进行人肉迁移数据，对比了表里的数据一模一样，但是无论如何checksum就是不一致，那么问题出在哪里呢？ 问题排查 数据是否一致 眼睛都把屏幕盯穿了，也没发现不一致的数据。 导出数据的方式

 checksum还是不一致，所以这个原因排除。

【mysql】  【SQL】  【checksum】   点击查看原文>

序列化和写盘 Tokudb数据节点写盘主要是由后台线程异步完成的： checkpoint线程：把cachetable（innodb术语buffer pool）中所有脏页写回 evictor线程：释放内存，如果victim节点是dirty的，需要先将数据写回。

【mysql】  【函数】  【线程】  【源码】  【node】  【tokudb】  【checksum】   …

告警日志发现报错 2016-12-05 13:01:23 27830 [ERROR] /usr/sbin/mysqld: Table './user/t_customer' is marked as crashed and should be repaired 2016-12-05 13:01:23 27830 [ERROR] /usr/sbin/mysqld: Table '.

【mysql】  【innodb】  【checksum】  【myisam】   点击查看原文>

[MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题

1.停掉慢查询 2.停掉无关的服务 3.停掉从库

1.在刚开始的时间，导出show full processlist; mysql -uroot -p'xx' -Ne "show full processlist;" > /root/process.

【mysql】  【SQL】  【索引】  【CPU】  【checksum】  【binlog】   点击查看原文>

MySQL的性能从查看日志开始。硬件配置低常常导致这样的问题，但事实上大多数情况并不在这里。某些“慢"SQL阻塞了其他语句的执行，优化查询是第一步需要做的。     “工欲善其事必先利其器”，MySQL自身的一款mysqldumpslow 查询日志分析器，该工具不但陈旧，验证规范不准确。

【mysql】  【memcached】  【SQL】  【日志】  【LOG】  【review】   …

在MySQL主从复制过程中，常常需要对某些重要的表进行一致性检查。     由于主从数据在同步时存在一定的延迟，因此直接读取服务器数据的方式无法严格保证信息的一致性。在数据在同步完全结束之前，一直处于不断变化且并不完整的状态下。

【mysql】  【同步】  【Server】  【checksum】  【IT】   点击查看原文>

主从复制不一致的情况解决： 不一致的原因：

1、 主从切换时，出现的故障

2、 误操作

3、 机器故障等 方法一：利用MySQL原生的mysqldump就可以搞定，对于个别表有锁表的情况。 可以参考：http://hcymysql.

【算法】  【mysql】  【同步】  【索引】  【数据同步】  【checksum】   …

  关于5.X的系统定制，网上有不少很好的资料，但本人在实践6.X系统定制的时候，遇到问题不少，此文是对本次系统定制的一个总结，大家多多交流。 centos6.2X86_64有两张DVD，第二张DVD也用得到，所以定制光盘的时候，需要把两张光盘都下载到本地。

【mysql】  【centos】  【xml】  【checksum】  【timestamp】  【source】   …

mysql 数据     1.   数据库定义语言（数据定义语言DDL）         a.   alter database         b.   create database         c.

【mysql】  【函数】  【数据库】  【索引】  【Transaction】  【analyze】  【index】   …