到底我该选哪个PostgreSQL宣称是：The world’s most advanced open source databaseMySQL则宣称是：The world’s most popular open source database而我的观点是选择最合适的，而不是“最好”的！那么，什么才是最合适的呢，我想有几点：哪个数据库的使用量够大，从业者够多。人多力量大，有问题也能更早、更容易发现，更容易解决。最最最重要的，招人更快（小道消息：知数堂的MySQL DBA课程，已为行业培养了众多优秀DBA人才，可以到我们这里直招哟，发送“开班”了解详情）。在项目初始时，某关键技术负责人的喜好基本直接决定了用哪个数据。大部分开发工程师更熟悉哪种数据库就选哪个。某些具体技术细节上的优劣，并不能直接决定最终的选择！ 毛爷爷教导过我们，要实事求是。凡事要根据实际情况而定，不能因为我对MySQL最熟悉，所以要在所有业务场景下都选择MySQL（比如大数据分析场景），那显然也是很愚蠢的做法，会害了整个项目。某公司高调宣传从某种数据库转变成另一种数据库时，作为从业者，我们更应该冷静看待、分析，到底因为哪些因素才促使他们作出新的选择，我们的业务中是否也有这些痛点。切！忌！盲！目！跟！风！毕竟，虽然是以某公司的名义发布的文章，其实很可能仅仅只是公司内部的一个项目而已。就 ...继续阅读 (29)

2016.7.28知数堂培训推出免费在线分享《DBA神技之SQL Review》1、分享主题《DBA神技之SQL Review》2、嘉宾介绍吴炳锡，知数堂培训联合创始人，前新媒传信首席DBA、MySQL中国用户组（ACMUG）主席，吴炳锡老师具有多年MySQL及系统架构设计及培训教学经验，擅长MySQL大规模运维管理优化、高可用方案、多IDC架构设计，以及企业应用数据库设计等经验。3、主题介绍在DBA工作中，有个重要内容是做SQL Review。面对成千上万的SQL时，如何判断每个SQL的质量高低，怎么从中快速找到那些“害群之马”，有什么神技吗。此外，线上Schema和SQL怎么进行优化，也特别考验DBA的综合能力。让我们一起来看看，DBA进行SQL Review时都有那些神技可用。AgendaDBA要做哪些SQL Review工作Schema Review的注意事项SQL Review的注意事项线上Schema分析、优化技巧线上SQL分析、优化技巧其他分享时间：2016.7.28（周四） 晚上20:30 – 21:30分享方式：YY语音直播，在QQ&微信群发送PPT等图文内容YY频道：53695719（需提前安装YY客户端，支持windows/ios/andriod多平台）知数堂分享QQ主群：529671799（加群暗号：知数堂）扫描下面二维码加入QQ群QQ群 ...继续阅读 (18)

0、导读主从复制环境中，IO、SQL线程都很正常，也没设置过滤规则，但数据就是无法复制到slave上，什么原因？1、问题描述事实上，这个案例发生已经有一阵子了，一直拖到现在我才整理。发现一个主从环境中，slave上的io_thread、sql_thread状态均正常，relay log也正常接收来自master的event，但slave上却无法正常应用这些event，个别表数据没有复制过来。而且slave上的binlog也没有记录这些表上的操作。2、原因分析接到现场后，第一反应是是先检查是否设置了ignore/do规则，发现并不是这个原因引起的。我自己手动测试创建了个新的测试表，写了几条数据，发现在slave上这个表能被创建，但写入的测试数据仍旧无法复制过来。这说明，slave上的复制并不是完全失效的，只是有特殊情形下才会失效。结合上面的问题，想到了可能是因为binlog format以及事务隔离级别等原因导致失效的，于是做了下面的尝试。//首先修改事务隔离级别为RR（此前是RC），尽可能保证主从数据一致性root@imysql [mydb]> set session transaction isolation level repeatable read;//测试写入2条数据root@imysql [mydb]> insert into z select 5,5;roo ...继续阅读 (40)

0、导读有个采用子查询的DELETE执行得非常慢，改写成SELECT后执行却很快，最后把这个子查询DELETE改写成JOIN优化过程1、问题描述朋友遇到一个怪事，一个用子查询的DELETE，执行效率非常低。把DELETE改成SELECT后执行起来却很快，百思不得其解。下面就是这个用了子查询的DELETE了：[yejr@imysql.com]mydb > EXPLAIN delete from trade_info where id in (select id from (select a.id from trade_info a, order_info b, user c whereb.buyer = c.id and c.itv_account=’90000248′ and a.order_id = b.id) temp)\G几个表的DDL是这样的：上面这个SQL的执行耗时是：31.74秒Query OK, 5 rows affected (31.74 sec)如果我们把DELETE改写成SELECT的话，执行耗时仅是：0秒，来对比看下执行计划：[yejr@imysql.com]mydb >EXPLAIN select id from trade_info whereid in (select id from (select a.id from ...继续阅读 (16)

0、导读在MySQL 5.7下采用多源复制方式，从5.6复制数据过来，会有问题吗？1、问题描述Q群里有位朋友想尝鲜5.7的多源复制，于是用MySQL 5.7版本作为slave，把MySQL 5.6作为master，想要将数据进行汇总，发现此路不通。他在my.cnf中设置了2个选项，开启并发复制：slave_parallel_type    = LOGICAL_CLOCKslave_parallel_workers = 4启动复制线程后，结果在错误日志中不断有类似下面的信息：Transaction is tagged with inconsistent logical timestamps: sequence_number (823267087) <= last_committed (1301275374434324336)执行 SHOW SLAVE STATUS\G 查看状态：*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event…Last_Errno: 1756Last_Error: … The slave coordinator and worker threads are stopp ...继续阅读 (36)

知数堂资深MySQL讲师，前新媒传信首席DBA、MySQL中国用户组（ACMUG）主席吴炳锡老师在5月19日晚上20:30做了在线分享《如何针对业务做DB优化》，受到了很多朋友的肯定和支持。也要再次感谢KVM虚拟化实践社区&Ceph中国社区的鼎力支持。1、分享资料下载百度云盘链接:http://pan.baidu.com/s/1mhSgnlm 密码:2ycr，欢迎转存并再次分享。2、本次分享PPT这次的PPT我也在slideshare上放了一份。 ...继续阅读 (21)

0、导读用LOAD DATA导入数据却一直提示主键冲突问题解决案例。1、问题描述有位学生遇到数据导入时一直提示1022主键冲突问题，而导入的数据明明完全没有任何冲突，百思不得其解，请我帮忙协查。下面是关于该问题现象描述：1、表结构DDLCREATE TABLE `wcp` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`txcode` char(4) NOT NULL,`notice_from` enum(‘page’,’server’) ,`message` varchar(600) NOT NULL ,`signature` varchar(260) NOT NULL ,`payment_no` char(30) NOT NULL ,`notice_time` int(10) unsigned NOT NULL COMMENT ,`dealt_ok` tinyint(1) NOT NULL DEFAULT ‘0’ COMMENT,PRIMARY KEY (`id`)) ENGINE=ARCHIVE AUTO_INCREMENT=117 DEFAULT CHARSET=utf8;欲导入的数据有116条，可以非常肯定的是，主键值都是顺序增长的，完全没有冲突，所以感 ...继续阅读 (17)

这是上周末在第二节全球PHP开发者大会上分享的内容，本来打算周六晚上就发布的，但因为拖延症又发作了，直到现在才发布，嘿~这次的PPT我也同时放到百度云盘里了，欢迎下载转存。百度云盘链接:http://pan.baidu.com/s/1pKX1qTt密码: y7ut ...继续阅读 (30)

0、导读在slave上，发现SQL thread长时间处于Opening tables状态1、问题描述朋友的数据库，做了主从replication复制。在slave实例上，SQL thread的长时间处于Opening tables状态，复制进程异常。mysql> show processlist;+—-+————-+———–+——+———+——-+—————————————-+——————+| Id | User        | Host      | db   | Command | Time  | State                                  | Info             |+—-+————-+———–+ ...继续阅读 (18)

0、导读在复制环境中，有个表的列类型总是被修改，导致复制进程报错停止1、问题描述问题发生在朋友的数据库上，做了主从复制，其中某表有一列类型是INT，但是该表上的INSERT事件在BINLOG中却总被记录为MEDIUMINT类型，导致这个事件在SLAVE上执行失败。相关现场信息见下：MySQL版本：官方5.5.版本。表DDL定义：CREATE TABLE `t` (`userid`int(10)unsigned NOT NULL DEFAULT 0,这个表上的INSERT事件在BINLOG中的记录：### INSERT INTO `imysql`.`t`### SET###   @1=207 /*MEDIUMINTmeta=0 nullable=0 is_null=0 */我们看到BINLOG中，这个列类型显示为MEDIUMINT，这个事件在SLAVE上就会报告下面的错误，导致SLAVE无法继续复制：Column 0 of table ‘imysql.t’ cannot be converted from type ‘mediumint’ to type ‘int(10) unsigned又是一个看起来很奇葩的案例。2、原因分析经过沟通排查，了解到他们的业务模式有点特殊，是从一个旧的空表中复制表结构生成每天日志表，然后再将当 ...继续阅读 (20)

2016.4.20KVM虚拟化实践社区&知数堂联合在线分享《从案例说InnoDB的基本优化》圆满结束本文进行总结并且发布视频&PPT资源分享主题《从案例说InnoDB的基本优化》嘉宾介绍叶金荣，资深MySQL专家，ORACLE MySQL ACE国内最早的MySQL推广者，从事MySQL相关工作10余年，擅长MySQL性能优化。个人网站http://imysql.com始建于2006年，是国内第一个MySQL专业技术站点个人公众号：MySQL中文网（imysql_wx)主题介绍从一个MySQL的ibdata1文件size急剧暴增的案例说起，具体深入解读原因，并由此展开来讲讲如何对InnoDB引擎进行优化。Agendaa.  MySQL的ibdata1文件size暴增案例解析b.  MySQL InnoDB引擎特点介绍c.  MySQL InnoDB引擎优化建议问题交流Q1：长时间执行的事务 因为增长 强行杀掉 会不会出现回滚需要更长时间？答：发生大事务回滚时，如果把mysqld进程强行kill，在MySQL 5.5以前的版本确实会比较慢；而从5.5及以后的版本中，做就很快了，大概也就最多1-2分钟。如果不是强行把mysqld进程kill，只是把大事务所在线程kill导致事务回滚，那么就需要较久的时间了，因此强烈建议几点：a. 不要在一个事务中修改大量数据；b. 不要 ...继续阅读 (21)

0、导读往表里写入新数据时，却一直报告主键冲突，某列值一直被重置为一个固定值，疑似被黑，啥情况？1、问题描述某朋友的线上数据库，怀疑被侵入了。具体表象是：INSERT的时候，某列值总被自动改成一个固定值。他们先自查了 TRIGGER 和 EVENT，都是空的，确定不是因为这两种原因引起，实在想不出是哪里被动了手脚。问题的现象：MariaDB [information_schema]> use bbs9;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -ADatabase changedMariaDB [bbs9]> INSERT INTO cdb_mythreads_latest (uid,username,tid,fid,subject,special,dateline) VALUES (‘1239009‘,’yayv’,’13482713‘,’815′,’bbs5 …………….’,R ...继续阅读 (22)

0、导读在MySQL里，如何识别并且避免发生SQL注入风险1、关于SQL注入互联网很危险，信息及数据安全很重要，SQL注入是最常见的入侵手段之一，其技术门槛低、成本低、收益大，颇受各层次的黑客们所青睐。一般来说，SQL注入的手法是利用各种机会将恶意SQL代码添加到程序参数中，并最终被服务器端执行，造成不良后果。例如，我们访问接口 http://imysql.com/user.php?userid=123 来根据userid获取用户信息，假设程序中是这么处理的：$sql = “SELECT * FROM user WHERE userid =$_GET[userid]“;上面这段代码看起来既low有很xx对吧，尤其是在双引号里面还可以直接引用数据类型变量，所以说php是世界上最好的语言一点不为过，哈哈（其实我早期也写过几年php的）。这时候，如果我们传递进去的参数改成这样：http://imysql.com/user.php?userid=123 or 1=1，这就会导致SQL条件永远成立，所有的数据都会被读取出来。又或者可以传递这样的参数：http://imysql.com/user.php?userid=123 or if(now()=sysdate(),sleep(5),1)，这时候不但所有的数据都会被读取到，也会让这个SQL执行完毕后再等待5秒才能返回 ...继续阅读 (11)

知数堂2016年第二次在线分享活动启动，由资深Python专家张老师为我们带来主题分享《魅力Python》，张老师是某大型公司云计算docker方向后台开发负责人，具有5年以上Python开发经验，原360安全卫士自动化部门开发工程师随着云平台的发展，对于传统运维压力非常大，也将面临淘汰的危机。 在云的背景下，对于运维和DBA也提出了新的要求：具备开发能力，Python是一门万能的胶水语言，在系统运维，数据抓取，中间层调用，大数据方面都有较好的使用案例本次主要内容有：1    Python能做什么1.1   Python 是我们工作中的得力助手1.2   Python 给我们生活带来的乐趣1.3   Python 带来的便利2    掌握Python对我们提升工作能力的帮助2.1   如何成为Python开发工程师2.2   作为DBA掌握Python的好处是什么3    如何学好Python4    我们的课程能够给你带来什么4.1   Python快速入门4.2  快速提升Python能力4.3  掌握用Python开发后台web服务能力 分享时间：2016.03.31 20:30 – 22:00参加分享请提前加入QQ群 373900864（暗语：PY大法好），YY语音直播频道 86142750。听完分享并立刻报名参加“知数堂Python培训”，即可以获得 ...继续阅读 (48)

0、导读MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全？MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全。数据安全如果只靠MySQL应用层面显然是不够的，是需要在多个层面来保护的，包括网络、系统、逻辑应用层、数据库层等。下面是我们可借鉴的一些安全策略。1、网络、系统层面在这个层面可以做很多的事情，我们可以把这些安全要求作为新系统安装时的标准要求，放到自动化装机方案中。把运行MySQL的服务器放在内网中，不要启用公网；迫不得已启用公网的话，修改sshd端口到10000以上；设置防火墙策略，只允许信任的服务器连接sshd和MySQL端口；修改idrac/imm密码，设置GRUB密码；设置密码安全策略，比如要求 PASS_MIN_LEN 不低于8位，其实最好是直接用一个复杂密码做MD5之后再作为正式密码，32位长度的安全程度够高吧；将操作日志记入syslog并且发送到远程log server上，坚决不能只存储在本地；除了必须的账号，其他的都设为无登入权限；尽量把运行MySQL的服务器独立出来，不要和web server、app server放一起。必须放一起的话，也要设置好权限分离，不允许web server、app server进程的属主有直接访问MySQL datadir的权 ...继续阅读 (6)

知数堂2016年首次在线分享活动启动，由资深MySQL专家、MySQL中国用户组（ACMUG）主席吴炳锡给大家带来《MySQL响应慢排查技巧》，吴炳锡老师具有多年MySQL及系统架构设计及培训教学经验，擅长MySQL大规模运维管理优化、高可用方案、多IDC架构设计，以及企业应用数据库设计等。本次主要内容有：1、如何定位性能瓶颈；1.1、如何分析CPU是否有瓶颈；1.2、如何分析I/O是否有瓶颈；1.3、如何分析内存是否有瓶颈；1.4、其他瓶颈原因分析；2、如何分析数据库状态；2.1、MySQL关键状态分析；2.2、InnoDB关键状态分析；2.3、其他关键状态分析；3、如何进行针对性优化；3.1、慢日志收集分析；3.2、锁等待或死锁分析；3.3、其他情况分析；3.4、案例总结。 分享时间：2016.03.15 20:30 – 22:00（和央视315晚会同时） 参加分享请提前加入QQ群373900864（暗语：不约而同），YY语音直播频道86142750。听完分享并立刻报名参加“知数堂MySQL DBA培训”，即可获得7期报名特惠价6800元（预计4月中下旬起将涨价），点此链接直达 http://t.cn/RU6UR4q （其他宝贝不参与此活动）。课程咨询QQ：982892381、1037447289、4700963、82565387。 “ ...继续阅读 (18)

0、导读遇到InnoDB的共享表空间文件ibdata1文件大小暴增时，应该如何处理？1、问题背景用MySQL/InnoDB的童鞋可能也会有过烦恼，不知道为什么原因，ibdata1文件莫名其妙的增大，不知道该如何让它缩回去，就跟30岁之后男人的肚腩一样，汗啊，可喜可贺的是我的肚腩还没长出来，hoho~正式开始之前，我们要先知道ibdata1文件是干什么用的。ibdata1文件是InnoDB存储引擎的共享表空间文件，该文件中主要存储着下面这些数据：data dictionarydouble write bufferinsert buffer/change bufferrollback segmentsundo spaceForeign key constraint system tables另外，当选项innodb_file_per_table = 0时，在ibdata1文件中还需要存储 InnoDB 表数据&索引。ibdata1文件从5.6.7版本开始，默认大小是12MB，而在这之前默认大小是10MB，其相关选项是innodb_data_file_path，比如我一般是这么设置的：innodb_data_file_path = ibdata1:1G:autoextend当然了，无论是否启用了innodb_file_per_table = 1，ibdata1文件都必须存在，因为 ...继续阅读 (9)

0、导读想往一个表里添加一个自增列做主键，居然失败报告无法读取，这是怎么回事？1、问题描述有位朋友在升级discuz论坛数据库时遇到问题了，想给一个表添加自增列做主键，结果发生下面的报错：mysql> ALTER TABLE pre_common_credit_log ADD `logid` mediumint(8) unsigned NOT NULL AUTO_INCREMENT FIRST, ADD PRIMARY KEY (logid) ;ERROR 1467 (HY000): Failed to read auto-increment value from storage engine2、原因分析从报错信息来看，第一反应是：数据表损坏了。不过，再仔细想想，肯定不是啊，否则报错也不是这个了，而是像下面这样的了：1030 Got error -1 from storage engine再仔细一想，更大的可能性是：该表里的总数据量，超过了mediumint最大值所致。让朋友把自增列数据类型改成int或者bigint，果真就好了。3、其他建议建议使用discuz的同学们可以考虑这么做：如果启用了抢楼功能，那么就把post相关的表继续保留使用MyISAM引擎。或者自己动手改造代码，把抢楼功能中的楼梯值用redis来存储；如果没有启用抢楼功能，那么就可以放心的把所有表引擎改成In ...继续阅读 (23)

0、导读本文介绍MySQL的index extensions特性，以及如何利用这个特性实现SQL查询优化。1、什么是index extensionsindex extensions是MySQL 5.6.9之后的新特性，关于这个特性，手册中的解释是这样的：InnoDB automatically extends each secondary index by appending the primary key columns to it（出处详见手册8.2.1.7 Use of Index Extensions，原文链接：https://dev.mysql.com/doc/refman/5.6/en/index-extensions.html简言之就是，InnoDB引擎表中，会把主键所有列值附加存储在辅助索引中。假设有这样一个表：CREATE TABLE t(a int not null,b int not null,c int not null,d int not null,PRIMARY KEY(a, b),KEY i_c(c)) ENGINE=InnoDB;意思是，该表中的辅助索引i_c的索引键值，实际上也同时存储了主键中的两个列值，也就是说，i_c的索引数据结构中，实际上存储的列是：c、a、b三列的值。我们可通过innodb_table_monitor查看验证下：TABLE: ...继续阅读 (11)

0、导读我们知道，MySQL里可以动态修改事务隔离级别（TRANSACTIOIN ISOLATION LEVEL），既可以加GLOBAL关键字直接修改全局的设置，也可以加SESSION关键字只修改当前会话的设置。那么，如果两个关键字都不加，会出现什么情况呢？1、调整事务隔离级别MySQL里，可以直接用 SET 指令调整事务隔离级别，既可以对全局调整，也可以只调整当前会话，其用法见下：SET [GLOBAL | SESSION] TRANSACTION[ REPEATABLE READ| READ COMMITTED| READ UNCOMMITTED| SERIALIZABLE ]我们都知道指定 GLOBAL 关键字是可以修改全局的设置，用这个方式修改完后，已经存在的连接还不会生效，只有对新建立的连接才会起作用。而指定 SESSION 关键字则是只修改当前连接会话的设置，修改完后立即生效，再次连接后会恢复成全局的设置，对其他连接/会话也不起作用。另外，如果都不指定 GLOBAL、SESSION 关键字，会发生什么情况呢？官方文档给出的解释是这样的：Without any SESSION or GLOBAL keyword, the statement applies to the next (not started) transaction performed within the ...继续阅读 (11)

0、导读本文主要写给那些立志成为MySQL DBA，以及正在学习MySQL的同行们，结合个人及业内其他同行的职业发展经历给大家一些参考，如何成为合格的MySQL DBA。1、什么是MySQL DBA首先，DBA是database administrator（数据库管理员）的简称，在一些招聘网站上，也可能会把职位写成数据库[管理]工程师，MySQL DBA是目前互联网企业中最为炙手可热的岗位需求之一，前（钱）景大好，快到碗里来吧。下面是拉勾网的MySQL DBA招聘需求（若无“MySQL中文网水印”的二维码请勿打开）：2、MySQL DBA的职责传统意义上的DBA基本上只要管好database system就可以，一般无需关注操作系统、硬件、网络、安全、NOSQL等相关技术细节，在一些传统企业或者操作集成商里的ORACLE DBA就是这样的，最多关注到主机（小机为主）及相应的存储设备。而MySQL一般在互联网业务中使用，MySQL DBA需要关注的方面也相应更多了，主要就是上面提到的主机硬件、OS、网络、安全、NOSQL，以及一些MySQL运维自动化开发（这不奇怪，一个好平台，通常都要自己亲自开发才顺手）的工作。此外，随着企业规模的变化，可能在公司初期是由一些比较资深的开发工程师负责所有服务器大小事宜，当然也包括MySQL的管理及优化。随着规模的扩大，可能改由运维工程师来负责这些事了 ...继续阅读 (15)

导读遇到SLAVE延迟很大，binlog apply position一直不动的情况如何排查？问题描述收到SLAVE延迟时间一直很大的报警，于是检查一下SLAVE状态（无关状态我给隐去了）：Slave_IO_State: Waiting for master to send event         Master_Log_File: mysql-bin.000605     Read_Master_Log_Pos: 1194          Relay_Log_File: mysql-relay-bin.003224           Relay_Log_Pos: 295105   Relay_Master_Log_File: mysql-bin.000604        Slave_IO_Running: Yes       Slave_SQL_Running: Yes              Last_Errno: 0              Last_Error:     Exec_Master_Log_Pos: 294959         Relay_Log_Space: 4139172581   Seconds_Behind_Master: 10905可以看到，延迟确实很大，而且从多次show slave status的结果来看，发 ...继续阅读 (14)

导读从一个现场说起，全程解析如何定位性能瓶颈。排查过程收到线上某业务后端的MySQL实例负载比较高的告警信息，于是登入服务器检查确认。1. 首先我们进行OS层面的检查确认登入服务器后，我们的目的是首先要确认当前到底是哪些进程引起的负载高，以及这些进程卡在什么地方，瓶颈是什么。通常来说，服务器上最容易成为瓶颈的是磁盘I/O子系统，因为它的读写速度通常是最慢的。即便是现在的PCIe SSD，其随机I/O读写速度也是不如内存来得快。当然了，引起磁盘I/O慢得原因也有多种，需要确认哪种引起的。第一步，我们一般先看整体负载如何，负载高的话，肯定所有的进程跑起来都慢。可以执行指令w或者sar -q 1来查看负载数据，例如：[yejr@imysql.com:~ ]# w 11:52:58 up 702 days, 56 min, 1 user, load average: 7.20, 6.70, 6.47 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 1.xx.xx.xx 11:51 0.00s 0.03s 0.00s w或者sar -q的观察结果：[yejr@imysql.com:~ ]# sar -q 1 Linux 2.6.32-43 ...继续阅读 (18)

导读在MySQL里常用的索引数据结构有B+树索引和哈希索引两种，我们来看下这两种索引数据结构的区别及其不同的应用建议。二者区别备注：先说下，在MySQL文档里，实际上是把B+树索引写成了BTREE，例如像下面这样的写法：CREATE TABLE t(aid int unsigned not null auto_increment,userid int unsigned not null default 0,username varchar(20) not null default ‘’,detail varchar(255) not null default ‘’,primary key(aid),unique key(uid) USINGBTREE,key (username(12)) USINGBTREE—此处 uname 列只创建了最左12个字符长度的部分索引)engine=InnoDB;一个经典的B+树索引数据结构见下图：(图片源自网络)B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接。在B+树上的常规检索，从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动，而且基于索引的顺序扫描时，也可以利用双向指针快速左右移动，效率非常高。因此，B+树索引被广泛应用于数据库、文件系统等场景。顺便说一下，xfs文件系统比ext3/e ...继续阅读 (24)

导读MySQL里如何监控平均SQL响应时长？问题由来对MySQL的性能指标监控，除了关注tps（每秒可执行的事务数）、qps（每秒请求数）两个衡量吞吐量的重要指标外，还应该监控平均SQL响应时长指标。怎么做有几个可选方案：1、利用MySQL提供的benchmark()函数。这个函数的作用是模拟进行N次某种调用，这样一来，我们就可以利用这个函数调用N次专门的存储过程，根据其执行耗时，以此作为平均SQL响应时长的依据；2、利用pt-query-digest工具，并结合tcpdump实时抓取每个SQL请求，也就能分析出每个SQL请求的响应时长了；3、使用Percona或者MariaDB分支版本提供的QUERY_RESPONSE_TIME插件功能，它可以帮我们统计平均SQL响应时长的分布区间，类似直方图功能；第一种相对比较简单但不够精确（不过也是够用的），第二种略麻烦些但可以看到每次请求的详细记录，第三种则只能看到整体的分布，无法看到每次请求的详细记录。写在最后监控性能指标时，除了关注吞吐量，还应该关注每次请求的平均响应时长。以高速公路收费站为例，有几个收费口基本可表示其并发收费能力（tps），而每辆车的平均通行时间如果很久的话，相信你也是受不了的是不是 ：） 关于MySQL的方方面面大家想了解什么，可以直接留言回复，我会从中选择一些热门话题进行分享。 同时希望大家多多转发，多一 ...继续阅读 (15)

导读关于 lower_case_table_names 选项的设置的建议是怎样的呢？问题由来我个人认为，纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来，在这两个数据库系统中，都无需关心数据表的大小写。而在MySQL中，默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的)，除非在windows系统下(windows系统是不区分大小写的)。老叶的建议我在公司制定的规范是要求默认设置lower_case_table_names=0的，也就是区分大小写。那么问题来了，如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢？我的建议是：首先，检查确认在应用程序中（或者抓取一段时间的请求日志），数据表名的写法是大写、小写还是混用，如果都是大写或者都是小写，那就更简单些了；其次，根据上面检查的结果，确定迁移到MySQL后统一使用大写还是小写（使用哪种规则的改动代价更小）；最后，利用Linux下的awk\sed等工具，将包含数据表关键字的地方全部替换成第二部定义好的表名方案；这样一来，就可以完成数据表名方案的切换了。当然了，肯定有人（比如某领导、某PM，你懂得的，O(∩_∩)O哈哈~）会说全部修改表名风险太大，需要全面测试，这个项目时间进度很紧张，希望能先上线。这种情况就没办法了，只能闲设置lower_case_tabl ...继续阅读 (17)

说正事前，先容我先扯扯。关于晨跑大概2个月前，我调整了下跑步时间。以前是下班后约上同事去公司附近的公园跑步，之后再回去吃饭。现在则改成了早晨6点起来，独自一人在附近的公园跑步。相对于前者，后者的好处多多：通过早起反过来督促早睡，搞IT的都习惯晚睡，这点非常不好。晨跑结束后，洗个热水澡，一整天精神都会很好；跑步时间更充裕，6点起来，9点半上班，中间有大段的时间，现在我一般都持续跑10公里约1个小时多一点；由于晨跑的时间比较充裕，跑步过程中可以安心思考一些事情，不像夜跑，可能要非常专注看路什么的，今天的这篇短文就是晨跑中构思起来的；关于晨跑的建议：一开始可能无法早起，可以先定个闹钟，强迫自己坚持早起1周，1周后估计就基本上能适应了，然后就可以开始愉快健康的晨跑之旅了。关于跑步烧钱这事在以前，单纯的以为跑步很省钱，没想到越来越烧钱。。。从2012年开始跑到现在，大概败了这些东西：买了3双鞋，约1K运动手表，约1.7k小腿套、髌骨贴、腰包、紧身衣，约0.5k数次外出参赛，合计约3k加起来也不是小数目了，看来以后少外出参赛，自己平时多跑跑就好了，哈哈。重要的事：MySQLer马拉松跑团招募想要搞这个跑团的出发点是鼓励各位MySQLer多运动、多健身、防猝死，同时也和CMUG组织结合起来，希望以后有机会拉到商业赞助，为跑团成员外出参赛提供一定额度的赞助，嘿嘿。怎么参加MySQLer马拉松跑团当 ...继续阅读 (18)

导读利用MySQL的event来自动维护表分区。我们去年就开始把zabbix数据库改成用TokuDB来支撑，并且启用了表分区（详情见：迁移Zabbix数据库到TokuDB）。这样做的好处很明显，较早的历史数据可以通过删除分区快速废弃掉。要知道，zabbix数据表默认是没有针对时间字段创建索引的，因此如果执行删除的SQL命令，其效率会很差，而直接删除分区就快多了。先看history表的分区规则：CREATE TABLE history ( itemid bigint(20) unsigned NOT NULL, clock int(11) NOT NULL DEFAULT '0', value double(16,4) NOT NULL DEFAULT '0.0000', ns int(11) NOT NULL DEFAULT '0', KEY history_1 (itemid,clock) ) ENGINE=TokuDB DEFAULT CHARSET=utf8 ROW_FORMAT=TOKUDB_QUICKLZ PARTITION BY RANGE (clock) (PARTITION p20150531 VALUES LESS THAN (1433088000) ENGINE = TokuDB, ... PARTITION p20160411 VALUES ...继续阅读 (33)

导读MySQL主从复制环境中，如何才能保证主从数据的一致性呢？关于主从复制现在常用的MySQL高可用方案，十有八九是基于 MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：在master上提交事务后，并且写入binlog，返回事务成功标记；将binlog发送到slave，转储成relay log；在slave上再将relay log读取出来应用。步骤1和步骤3之间是异步进行的，无需等待确认各自的状态，所以说MySQL replication是异步的。MySQL semi-sync replication在之前的基础上做了加强完善，整个流程变成了下面这样：首先，master和至少一个slave都要启用semi-sync replication模式；某个slave连接到master时，会主动告知当前自己是否处于semi-sync模式；在master上提交事务后，写入binlog后，还需要通知至少一个slave收到该事务，等待写入relay log并成功刷新到磁盘后，向master发送“slave节点已完成该事务”确认通知；master收到上述通知后，才可以 ...继续阅读 (20)

导读在群里向老叶提问的正确姿势是怎样的？我的QQ好友已超过1500人，其中至少有一半是曾经有过技术交流，或者找我帮助解决MySQL相关问题的。大致平均下来，每天约要帮忙解答2-3次问题。对我来说，这已然成了不小的额外“工作量”。因此，并不是所有的问题我都能回复，有些是能力不够，有些则是没兴趣回答，大概只有不到1/3的问题我会正面回复。先说下哪些是我没能力回答的吧，大概有下面这样的：想和我交流MySQL源码的，不好意思，我就一运维DBA，源码方面我并不擅长，倒是可以找阿里云RDS团队或其他同行聊聊；直接问我“这个SQL执行很慢，怎么优化呢”，也不好意思，只有这种一句话的问题描述，我确实没能力回答。真想获得帮助的话，可以参考下方的“提问的正确姿势”；“你好，我想实现xxx功能，请问SQL该怎么写呢”，更不好意思了，写SQL还真不是我的强项，非要勉为其难让我写的话，麻烦先给我发个红包，谢谢。有哪些是我没兴趣回答的呢？发来一条消息，问“在吗”。这是被我一直诟病的最糟糕的打招呼方式，平白无故浪费别人时间。心情好的时候，我或许会回一个“你猜/hi”，不好的时候，直接关掉当没看到；跟我说“老叶，能帮忙推荐一个牛一点的DBA吗，谢谢”。嗯，当然可以推荐，但麻烦您把大概要求说一下总可以吧，如果不是熟人，我的做法是直接关闭对话框；“请问MySQL里xxx命令是什么用途呢”，抱歉，我不是人肉查询机，麻烦 ...继续阅读 (18)