插图来自网络并作简单加工，如果觉得不当还请及时告知 ：）我们使用EXPLAIN解析SQL执行计划时，如果有下面几种情况，就需要特别关注下了：首先看下type这列的结果，如果有类型是 ALL 时，表示预计会进行全表扫描（full table scan）。通常全表扫描的代价是比较大的，建议创建适当的索引，通过索引检索避免全表扫描。此外，全索引扫描（full index scan）的代价有时候是比全表扫描还要高的，除非是基于InnoDB表的主键索引扫描。再来看下Extra列的结果，如果有出现Using temporary或者Using filesort则要多加关注：Using temporary，表示需要创建临时表以满足需求，通常是因为GROUP BY的列没有索引，或者GROUP BY和ORDER BY的列不一样，也需要创建临时表，建议添加适当的索引。Using filesort，表示无法利用索引完成排序，也有可能是因为多表连接时，排序字段不是驱动表中的字段，因此也没办法利用索引完成排序，建议添加适当的索引。Using where，通常是因为全表扫描或全索引扫描时（type列显示为ALL或index），又加上了WHERE条件，建议添加适当的索引。暂时想到上面几个，如果有遗漏，以后再补充。其他状态例如：Using index、Using index condition、Using inde ...继续阅读 (30)

插图来自网络并作简单加工，如果觉得不当还请及时告知 ：）一般而言，我们在processlist结果中如果经常能看到某些SQL的话，至少可以说明这些SQL的频率很高，通常需要对这些SQL进行进一步优化。今天我们要说的是，在processlist中，看到哪些运行状态时要引起关注，主要有下面几个：状态建议copy to tmp table执行ALTER TABLE修改表结构时建议：放在凌晨执行或者采用类似pt-osc工具Copying to tmp table拷贝数据到内存中的临时表，常见于GROUP BY操作时建议：创建适当的索引Copying to tmp table on disk临时结果集太大，内存中放不下，需要将内存中的临时表拷贝到磁盘上，形成 #sql***.MYD、#sql***.MYI（在5.6及更高的版本，临时表可以改成InnoDB引擎了，可以参考选项default_tmp_storage_engine）建议：创建适当的索引，并且适当加大sort_buffer_size/tmp_table_size/max_heap_table_sizeCreating sort index当前的SELECT中需要用到临时表在进行ORDER BY排序建议：创建适当的索引Creating tmp table创建基于内存或磁盘的临时表，当从内存转成磁盘的临时表时，状态会变成：Copying ...继续阅读 (20)

插图来自网络并作简单加工，如果觉得不当还请及时告知 ：）【场景】某个打算用于slave新搭建的实例启动报错，启动过程中报告InnoDB数据页发生损坏。错误日志像下面这样：150330 15:37:44 mysqld_safe Starting mysqld daemon with databases from /data/mysql/mytest_33062015-03-30 15:37:45 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).2015-03-30 15:37:45 5884 [Warning] Using unique option prefix myisam_recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.2015-03-30 15:37:45 5884 [Note] Plug ...继续阅读 (25)

图片来自Percona官网今天同事在用percona toolkit工具中的pt-table-checksum对主从数据库进行校验，提交命令后，一直提示下面的信息：Pausing because Threads_running=0看字面意思是在提示当前活跃线程数为0，但为什么不继续执行呢。这个提示信息有点含糊其辞，该工具是用Perl写的，因此直接打开看脚本跟踪一下，大概就明白怎么回事了，原来是这个工具有负载保护机制，避免运行时对线上数据库产生影响。和这个机制相关的参数名是：–max-load，其类型是：Array，用法是一个或多个variables = value组成的判断条件，然后根据这个规则判断某些条件是否超标。例如，设定–max-load=”Threads_running=25″，意思是当前活跃线程数如果超过25，就暂停 checksum 工作，直到活跃线程数低于 25。因此，在我们这个案例中，想要强制让 table-checksum 继续工作的话，可以设定 –max-load 的值，例如：pt-table-checksum --max-load="Threads_running=25" ...其他选项...或者pt-table-checksum --max-load="Threads_connected=25" . ...继续阅读 (20)

备注：插图来自网络搜索，如果觉得不当还请及时告知 ：）一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式（以InnoDB引擎为主）完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。另一个重要原因是，传统的MySQL复制是异步（asynchronous）的，也就是说在master提交完后，才在slave上再应用一遍，并不是真正意义上的同步。哪怕是后来的Semi-sync Repication（半同步复制），也不是真同步，因为它只保证事务传送到slave，但没要求等到确认事务提交成功。既然是异步，那肯定多少会有延迟。因此，严格意义上讲，MySQL复制不能叫做MySQL同步（处女座的面试官有可能会在面试时把说成MySQL同步的一律刷掉哦）。另外，不少人的观念里，slave相对没那么重 ...继续阅读 (24)

备注：插图来自discuz!官方LOGO，如果觉得不当还请及时告知 ：）写在前面：discuz!作为首屈一指的社区系统，为广大站长提供了一站式网站解决方案，而且是开源的（虽然部分代码是加密的），它为这个垂直领域的行业发展作出了巨大贡献。尽管如此，discuz!系统源码中，还是或多或少有些坑。其中最著名的就是默认采用MyISAM引擎，以及基于MyISAM引擎的抢楼功能，session表采用memory引擎等，可以参考后面几篇历史文章。本次我们要说说discuz!在应对热们帖子翻页逻辑功能中的另一个问题。在我们的环境中，使用的是MySQL-5.6.6版本。在查看帖子并翻页过程中，会产生类似下面这样的SQL：mysql> desc SELECT * FROM pre_forum_post WHERE tid=8201301 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 15\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: pre_forum_post type: ref possible_keys: tid,displayorder,first key: d ...继续阅读 (34)

备注：插图来自淘宝苏普的博客并保留水印，如果觉得不当还请及时告知 ：）写在前面：MySQL的query cache大部分情况下其实只是鸡肋而已，建议全面禁用。当然了，或许在你的场景下还是挺好的，还能发挥作用，那就继续使用吧，把本文当做参考就好。不过，可能有的人人为只需要把 query_cache_size 大小调整为 0 就可以了，可以忽略 query_cache_type 参数的值，反正它也是可以在线调整的。事实果真如此吗？让我们来实际模拟测试下就知道了。我们模拟了以下几种场景：1、初始化时，同时设置 query_cache_size 和 query_cache_type 的值为 0； 2、初始化时，设置 query_cache_size = 0，但设置 query_cache_type = 1； 3、初始化时，设置 query_cache_size = 0，query_cache_type = 1，但是启动后立刻 修改 query_cache_type = 0 4、初始化时，设置 query_cache_size = 0，query_cache_type = 0，但是启动后立刻 修改 query_cache_type = 1 5、初始化时，设置 query_cache_size = xMB，query_cache_type = 1，但是启动后立刻 修改 query_ca ...继续阅读 (16)

写在前面：在个别时候可能需要查看当前最新的事务ID，以便做一些业务逻辑上的判断（例如利用事务ID变化以及前后时差，统计每次事务的响应时长等用途）。通常地，我们有两种方法可以查看当前的事务ID：1、执行SHOW ENGINE INNODB STATUS，查看事务相关信息===================================== 150303 17:16:11 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 15 seconds ... ------------ TRANSACTIONS Trx id counter3359877657 -- 当前最大事务IDPurge done for trx's n:o < 3359877468 undo n:o < 0 state: running History list length 324 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0, not started-- 该会话中执行SHOW ENGINE INNODB STATUS，不会产生事务，所以事务ID为0MySQL thread id 469236 ...继续阅读 (32)

写在前面：我们在使用mysqldump备份数据时，请一定记住要加上-q参数，后果可能是很严重的，不要给自己挖坑哦。到底为什么呢，且听我慢慢道来！先来看看 mysqldump –help 中，关于 -q 参数的解释：-q, --quick         Don't buffer query, dump directly to stdout.简言之，就是说加上 -q 后，不会把SELECT出来的结果放在buffer中，而是直接dump到标准输出中，顶多只是buffer当前行结果，正常情况下是不会超过 max_allowed_packet 限制的，它默认情况下是开启的。如果关闭该参数，则会把SELECT出来的结果放在本地buffer中，然后再输出给客户端，会消耗更多内存。在mysqldump.c中也能看到二者的对比（现在流行深入源码，虽然我不是专注开发的，找几行源码能力还尚存，用来装B的，大家知道就好，哈哈）：if (quick) res=mysql_use_result(sock); else res=mysql_store_result(sock);有理论，也要有实践不是，我们来看看在实际场景中，加不加 -q 的区别有多大。部分备份（启用-q）部分备份（禁用-q）完整备份（启用-q）完整备份（禁用-q）备份总耗时27.882秒22.665秒277.387秒217 ...继续阅读 (22)

前言：作为没有自主研发能力的企业，MySQL、Percona、MariaDB到底该选择哪个？今天看到SOHU-DBA公众号推送的文章：《MySQL分支的选择：Percona还是MariaDB》，原文出处：http://www.biaodianfu.com/mysql-percona-or-mariadb.html，这个文章比较长，有兴趣的可以找到原文看看，我也来简单说下我的看法。就目前而言，我个人优先推荐使用Percona分支版本，它和官方版本相对是最近的，迁移切换的代价也很小。我从2008年开始就使用Percona分支版本到现在了，当初我们可是国内最大的Percona免费用户。最早只是在官方版本上打了一些补丁，现在已经发展形成了自己的XtraDB引擎，提供PXC高可用解决方案，并且附带了percona-toolkit等DBA管理工具箱，非常方便。而MariaDB分支则做了较大改动，虽然也集成了XtraDB引擎的大多数优势，但从官方版本迁移过去，不确定因素等风险还是挺大的，比如GTID不兼容、查询优化器个别时候更糟糕等等，不过MariaDB还是挺值得期待的。综上，建议先继续使用Percona分支，等MariaDB分支相对更成熟了再用不迟，对这两个分支都不感兴趣或不敢用的，再最后选择官方版本吧，把我上面的话当耳边风就行了，但我要告诉大家的是，在官方版本上能遇到奇葩的事情更多，尤其是查 ...继续阅读 (27)

Docker镜像：centos:centos6情景：通过yum升级glibc后，容器内部通过date命令看到时区自动被篡改，从CST改成了GMT分析：官方的centos:centos6镜像里的/etc/sysconfig/clock是这样的：ZONE=”Europe/London”UTC=True当通过rpm或yum升级glibc时候，glibc会自动读/etc/sysconfig/clock文件，然后修改时区，通过将/usr/share/zoneinfo/xx/yy覆盖/etc/localtime。规避方法有2种：1. 升级glibc前确保/etc/sysconfig/clock是正确的，或者删掉/etc/sysconfig/clock，这样glibc就不会去动时区了2. docker run -v /etc/localtime:/etc/localtime:ro ...继续阅读 (47)